Trying to write tests for my Java code that look pretty, work well, and are easy and quick to write is not possible to do in Java.
This is why I'm working on a new system which for now I'm calling "Java test script" to make it easy and quick to write tests that are pretty and do work well.
Screenshot! Pretty, right? The right part of the screen is Emacs editing the
.jts files which contain the scripts to run the tests. The left part of the screen is me using the command which performs the tests. The failing test is a demonstration in which I've edited the expected result to something incorrect.
So how does it work, you might ask? The answer is hilariously disgusting.
The command line
The answer is that I wrote the file parser for those
node, which then reads in the file, steps through it collecting and organising all the useful information, then reformats all of that information and inserts it into a
.java file, replacing parts of a
template.java that's hiding in another folder. The node process then writes out that
.java file to disk, uses
child_process to compile it, and then
child_process again to execute it, piping the Java process's stdout and stderr to its own stdout and stderr.
It's beautiful, right? : )
.jts is a file extension that I made up, but its format is designed to be similar enough to Markdown that you can use
markdown-mode to make it look pretty while you edit it.
.jts file spec
The file starts with an optional
@import section. Imports are separated by commas. There can be multiple lines with
@import, but they must be at the top of the file.
The file is then broken into sections that start with a
#. The text after the
# is the name of the section and is used as the name of each test inside it.
Each section must one or more of the following:
- A code block indented with 4 spaces. This code block will be run before the tests in the block.
- A test line starting with
-. Each test line starts with an expression (the actual value), then the text
should not equal, then the optional marker
json, then another expression (the expected value), and then optionally the marker
as arraywhich states whether the results of the expressions should be arrays. The
jsonmarker says whether the expected expression should be parsed as JSON and reformatted for Java (but only in array mode).
- A timer line starting with
*. The line of code will be run and timed. You can optionally add the marker
as <scale>to set whether the duration should be scaled as nanoseconds, milliseconds, seconds, minutes, hours...
It works really well for the fake things that I just made up to test the tester. Ironically, the tester isn't written in Java, so it can't test itself. I'll probably modify it in the future to cope better with the things that I'll actually need to test as part of COSC 241.