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 node run.js should have immediately set off a billion alarm bells inside your brain. JavaScript? That's a completely different programming language. How could I possibly be using it to talk to Java?

The answer is that I wrote the file parser for those .jts files in JavaScript, because I like JavaScript. I run the JavaScript file with 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 equal or should not equal, then the optional marker json, then another expression (the expected value), and then optionally the marker as array which states whether the results of the expressions should be arrays. The json marker 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.

— Cadence