Day 5

On the fifth day, you should specify test cases for the static analysis of MiniJava programs.

Initial Project

You should start the second milestone from a new initial project. First, either close or delete your project for the first milestone. Second, import the initial project^? using the Import > General/Existing Projects into Workspace wizard. Next, Build the project by selecting it and choosing Project > Build Project from the menu. The console will report success or failure. Finally, study the constructors used in ASTs. You can do this either by inspecting the AST of an example program or by inspecting the signature in assignment1/MiniJava.str.

Test Cases

Like in the first milestone, you should specify test cases before you start with the implementation. You need three types of test cases:

1. Tests for reference resolution. Define test cases for different kinds of references to declarations.
2. Tests for error checking. Define test cases for checking errors which are related to names and types.
3. Tests for transformations. Define test cases for the results of type projections.

Testing Reference Resolution

In test cases for reference resolution, you need to mark names at definition and use sites with inner square bracket blocks. You can then relate the use site with the definition site in a resolve ... to ... clause, using numbers to refer to the inner blocks. For example, the following two test cases require to resolve the type Foo to the name in the definition of class Foo:

test forward class name resolution [[
  class Main {
    public static void main(String[] args) {
      System.out.println(1);
    }
  }

  class Foobar {
    [[Foo]] x;
  }

  class [[Foo]] {}
]] resolve #1 to #2

test backward class name resolution [[
  class Main {
    public static void main(String[] args) {
      System.out.println(1);
    }
  }

  class [[Foo]] {}

  class Foobar {
    [[Foo]] x;
  }
]] resolve #2 to #1

Tip: You can use setup headers and footers to avoid repeating parts in similar test cases.

Testing Error Checking

In test cases for error checking, you need o specify the number of errors, warnings, or notes in a test case in ... errors, ... warnings, or ... notes clauses. You can use inner square bracket blocks to mark the positions where messages should be reported. For example, the following test cases specify a correct MiniJava program, a program with two errors which are reported on the name of a duplicate class Foo, and another program with a warning which is reported on the name of an unused class Foobar:

test correct program [[
  class Main {
    public static void main(String[] args) {
      System.out.println(1);
    }
  }

  class Foo {}

  class Foobar {
    Foo x;
  }
]] 0 errors

test error on duplicate class [[
  class Main {
    public static void main(String[] args) {
      System.out.println(1);
    }
  }

  class [[Foo]] {}

  class [[Foo]] {}
]] 2 errors

test waring on unused class [[
  class Main {
    public static void main(String[] args) {
      System.out.println(1);
    }
  }

  class Foo {}

  class [[Foobar]] {
    Foo x;
  }
]] 1 warning

Tip: An error might result in more then one error message shown in the editor. Thus, think carefully about the right number of errors in a test case.

Testing Transformations

Finally, you can test transformations by specifying the name of a strategy and the expected result in a with run ... to... clause. Again, you can mark the relevant part in the program with inner square brackets. For example, the following test case checks the result of applying type-of to an expression:

test type of addition is integer [[
  class Main {
    public static void main(String[] args) {
      System.out.println([[1+1]]);
    }
  }
]] run type-of to Int()

Required Test Cases

Name Analysis

You need to specify test cases for the resolution of

• class names,
• field names,
• method calls,
• parameter names, and
• variable names.

Additionally, you should have test cases for

• errors on duplicate definitions,
• errors on missing definitions,
• warnings on unused definitions,
• errors on cyclic inheritance,
• errors on hiding fields,
• warnings on hiding variables,
• errors on overloaded methods,
• notes on overriding methods, and
• errors on instantiating or subclassing the main class.

Type Analysis

You should specify test cases regarding the type-of strategy for all kinds of expressions. Additionally, you should have test cases for type-related errors in

• expressions,
• statements, and
• methods.