Lab 1(b): Creating Syntax Tests

Before getting started with your syntax definition, you set up a test suite for syntax analysis. Develop the test suite in tandem with the development of your syntax definition. The test suite consists of positive and negative test cases. We will not grade this test suite, but you should develop one to get confidence in the quality of your syntax definition. When you are asking for help from the course staff, we will first ask what tests you have written to demonstrate the problem.

Objectives

Develop a test suite for syntax analysis. The test suite should provide

1. Syntactically valid and invalid test cases for the Start sort
2. Disambiguation tests for associativity and precedence in expressions.
3. Test cases for layout-sensitive language constructs
4. Test cases for mandatory and optional whitespace.

Anatomy of a Test Suite

In Spoofax, a test suite consists of one or more .spt files. Consider the following example file:

module example

test FUN composite  [[func(1+1, 3*2)]] parse succeeds
test FUN only comma [[func(,)]]        parse fails

The first line specifies the name of the test module, In this example module, we test syntax of the ChocoPy language.

The last two lines specify a positive and a negative test case. Each test case consists of a name, a code fragment in double square brackets, and a condition which determines what kind of test should be performed (parsing) and what the expected outcome is (success or failure).

You get instant feedback while editing a test suite. Since you have not yet implemented the ChocoPy editor, all your positive test cases fail. You will work on this during the next lab. To read more on SPT, visit the documentation.

ChocoPy Syntax Definition

To write your own test cases, you need to understand ChocoPy’s syntax. You can find the definitive ChocoPy syntax definition in the Reference Manual.

Test Cases

You can now start writing your own test cases.

Lexical and Context-free Syntax

Start with the lexical syntax and think about valid and invalid identifiers. Try to focus on corner cases such as

• identifiers made of a single character,
• mixings of letters and digits (Which kinds of mixing are allowed? Which are not?),
• underscores in identifiers.

The content for the tests for lexical symbols should not be surrounded by layout.

Next, you should walk through the whole syntax definition. Keep thinking of valid and invalid code fragments. Identify interesting corner cases and turn them into positive and negative test cases.

Try to keep your test cases small. Each test case should focus on a single aspect. For example, a negative test case should only contain one error. The name of a test case should reflect the aspect it addresses.

You can organise test cases which focus on similar aspects in test modules. Again, the name of a test module should reflect these aspects. Finally, you can organise test suites in folders.

When writing tests that target the differences between Python and ChocoPy, only consider the syntactic differences. For example, identifiers in Python are limited to a certain size. This should not be checked by your tests as this limitation is not specified in the context-free grammar of Python.

Disambiguation

Next, you need to focus on disambiguation. Come up with positive test cases which specify the correct ASTs for nested expressions. As an alternative, you can also specify two fragments in concrete syntax, which should result in the same AST:

test left associative addition [[21 + 14 + 14]] parse to [[(21 + 14) + 14]]

You can find a table listing the associativity and priorities of operators in the reference manual. Do not focus only on binary expressions.

You do not have to test for constructs that are non-associative. In lab 2, non-assoc leads to semantic errors rather than syntactic errors during parse time. Since our language does not have analysis at that point, we cannot test the semantic errors and thus they are also not required for this lab.

Layout

Finally, you can focus on layout. Think about places where whitespace is not optional but mandatory and define corresponding positive and negative test cases. Finish with test cases for single-line comments. Single-line comments cannot only end with a newline character, but also at the end of file.

• Integrated language definition testing: enabling test-driven language development

  Lennart C. L. Kats, Rob Vermaas, Eelco Visser.

  OOPSLA 2011 [pdf, doi, bib, researchr, abstract]

  The reliability of compilers, interpreters, and development environments for programming languages is essential for effective software development and maintenance. They are often tested only as an afterthought. Languages with a smaller scope, such as domain-specific languages, often remain untested. General-purpose testing techniques and test case generation methods fall short in providing a low-threshold solution for test-driven language development. In this paper we introduce the notion of a language-parametric testing language (LPTL) that provides a reusable, generic basis for declaratively specifying language definition tests. We integrate the syntax, semantics, and editor services of a language under test into the LPTL for writing test inputs. This paper describes the design of an LPTL and the tool support provided for it, shows use cases using examples, and describes our implementation in the form of the Spoofax testing language.