oden/fine/tests
2024-02-07 07:58:36 -08:00
..
errors [fine] Parse alternate types 2024-02-01 07:56:30 -08:00
expression [fine] Conditionals produce alternates (yikes!) 2024-02-07 07:58:36 -08:00
example_tests.rs [fine] Static methods I guess 2024-01-25 06:44:53 -08:00
README.md [fine] OK 2024-01-13 15:07:38 -08:00

Snapshot Tests

The .fine files in this directory and its descendants are processed by build.rs into a series of snapshot-tests. The various test assertions are specified by @ directives in comments in the file.

e.g., a test might look like this:

// @concrete:
// | File
// |   ExpressionStatement
// |     BinaryExpression
// |       BinaryExpression
// |         LiteralExpression
// |           Number:'"1"'
// |         Star:'"*"'
// |         LiteralExpression
// |           Number:'"2"'
// |       Plus:'"+"'
// |       BinaryExpression
// |         UnaryExpression
// |           Minus:'"-"'
// |           LiteralExpression
// |             Number:'"3"'
// |         Star:'"*"'
// |         LiteralExpression
// |           Number:'"4"'
// |     Semicolon:'";"'
//
1 * 2 + -3 * 4;

// @type: 532 f64

Assertions

The various assertions are as follows:

  • The // @ignore directive marks the test as ignored.

  • The // @concrete: assertion says that the following lines (prefixed with // | , as above) describe the concrete syntax tree of the file after parsing.

    e.g.:

    // @concrete:
    // | File
    // |   ExpressionStatement
    // |     LiteralExpression
    // |       String:'"\"Hello world\""'
    // |     Semicolon:'";"'
    //
    "Hello world";
    
  • The // @type: assertion says that the type of the tree at the given point will match the given type. @type assertions usually go after the contents of the file to make the probe points more stable in the face of new assertions and whatnot.

    e.g.:

    "Hello world!"
    // @type: 2 string
    
  • The // @type-error: assertion says that the type of the tree at the given point should be an error, and that the error message provided should be among the generated errors. (Like @type, these usually go after the code, for stability.)

    e.g.:

    - "twenty five";
    // @type-error: 0 cannot apply unary operator '-' to value of type string