Attaching the java file. The program, called "ijToJUnit", takes as input the embedded master file corresponding to a .sql test and does a line-by-line mapping of that output file to corresponding JUnit calls. Note that the master file should be the embedded master (.out) file; the tool will not work with output files generated by Derby Client or JCC tests. That said, though, the JUnit commands generated by the tool are intended to behave the same regardless of the framework in use.
Usage: java ijToJUnit <embedded_sql_out_file>
While processing a master file, the tool may ignore lines that it thinks are irrelevant to the test. In that case the lines will be written to the output file with the tag "[**:: IGNORED ::**]" in front of them. If the tool encounters any lines in the .out file that it does not know how to convert, it will write the lines to the output file with the tag "[**:: UNCONVERTED ::**]".
Upon completion the tool prints out the number of lines it ignored, the number of lines it left unconverted, and the name of the output file that it generated. Theoretically, if the total number of lines ignored and unconverted is zero, the result file should be compilable as a JUnit test in Derby.
> java ijToJUnit altertable.out
==> Ignored 0 lines and left 22 lines unconverted.
==> Output is in 'altertable.junit'.
In this case no lines were ignored but the tool left all of the "show" and "describe" commands (and corresponding output) unconverted because those are ij-specific commands and thus the mapping to JUnit is not straightforward. It is then up to the user of the tool to examine the output file and figure out what to do with the ignored/unconverted output.
I ran the tool against a couple of the .out files in lang/ and in all cases the output had to be manually corrected in at least a couple of places before the test ran without error. So this is not a one-shot JUnit test creation tool. Once created the output will almost certainly need manual correction for formatting, long lines, or functional mis-conversions. And once that's done, the user will probably have to do a reorganization of the generated JUnit code so that it adheres to the recommended JUnit programming practices:
In particular, that link recommends small, independent test cases--but the ijToJUnit tool creates a single, large test method that encapsulates the entire .sql test. So even when the generated output has been manually fixed up to run without error, it may still need additional "good practice" changes.
The hope is that this ijToJUnit tool can help speed up the process of converting .sql tests to JUnit tests. It is not, however, meant to be a complete solution, nor is it by any means an intelligent one. It's just the (perhaps shameful) result of a hastily written "helper" utility that began one Friday afternoon.
Anyone interested should feel free pick it up and make it better. Or perhaps s/he will be inspired by the concept but will start from scratch and do a better job, which might be easier...