I'm also in the process of migrating the "failure" tests into the unit tests. Currently the failure tests work like this: There's a source file which contains example code which has errors in it - stuff that is supposed to fail. Each code snippet is preceded by a comment which contains a portion of the expected error message. The testrunner app attempts to compile each code snippet, and then compares the error messages produced with the comment.
The failure tests have not been updated in a long time. I've decided to get rid of the test runner - instead I have a new TestCompiler class that accepts the source code as a string, and which has various methods such as expectSuccess(), expectFailure(), expectWarning(), which integrate nicely with the Google test framework. This allows success tests and failure tests to be grouped together in the same source file, which should make it easier to maintain the tests. So far, about half the failure tests have been converted over. Here's a sample of what the tests look like:
EXPECT_COMPILE_FAILURE("class Test { adopted var test:int; }", "declaration modifier");EXPECT_COMPILE_FAILURE("class Test { readonly var test:int; }", "Use 'let'");EXPECT_COMPILE_SUCCESS("class Test { mutable var test:int; }");EXPECT_COMPILE_FAILURE("class Test { immutable var test:int; }", "Use 'let'");EXPECT_COMPILE_FAILURE("class Test { adopted let test:int; }", "declaration modifier");EXPECT_COMPILE_WARNING("class Test { readonly let test:int; }", "are always");EXPECT_COMPILE_FAILURE("class Test { mutable let test:int; }", "cannot be declared");EXPECT_COMPILE_WARNING("class Test { immutable let test:int; }", "are always");
The first argument is the source code to compile, and the second argument is the expected error message, or a portion of it.
I also took a bit of a break and added BitArray to tart.collections, with unit tests. That was fun to write.
No comments:
Post a Comment