[ http://issues.apache.org/jira/browse/DERBY-2151?page=all ]
A B updated DERBY-2151:
-----------------------
Attachment: ijToJUnit.java
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.
----
Ex:
> java ijToJUnit altertable.out
==> Ignored 0 lines and left 22 lines unconverted.
==> Output is in 'altertable.junit'.
Done.
----
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:
http://www.javaworld.com/jw-12-2000/jw-1221-junit.html
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... :)
> "Fixer-upper" utility to help convert ij canon-based tests to JUnit.
> --------------------------------------------------------------------
>
> Key: DERBY-2151
> URL: http://issues.apache.org/jira/browse/DERBY-2151
> Project: Derby
> Issue Type: Test
> Components: Test, Tools
> Affects Versions: 10.3.0.0
> Reporter: A B
> Priority: Minor
> Attachments: ijToJUnit.java
>
>
> As part of my work to get the XML tests running in JUnit (DERBY-1758) I had
> to convert the old ij test lang/xml_general.sql into a JUnit equivalent.
> After hand-converting about twenty or so lines of ij "master" output to the
> corresponding JUnit commands, I became bored with the melancholy of such a
> task. So I hastily threw together a small utility to help automate as much
> of the process as possible.
> To be perfectly frank, the utility is a shameful piece of code. It's
> poorly-written, non-intuitive, overly complex and not at all well
> thought-out. It's also completely UN-commented. I wish I could follow-up
> with a half-hearted claim that "at least it works", but I'm not even sure
> *that*'s always true...
> My first (and still lingering) inclination is to just bury the utility and
> never look at it again. However, I have to admit that, while the code is a
> nightmare to understand, it did a) prompt me to add some general-purpose
> JUnit utility methods that can be useful (DERBY-1976), and b) save me a lot
> of time by providing a rough translation of the ij test to JUnit. Then
> instead of piddling away at line-by-conversions of the test I was able to
> spend my time re-organizing the JUnit version to make it adhere to the JUnit
> suggestions on the second page of:
> http://www.javaworld.com/jw-12-2000/jw-1221-junit.html
> So the utility *did* save me time. And for that reason I've decided to choke
> down my embarassment and post it to a Jira issue for other developers who may
> find it useful (or perhaps entertaining as an example of bad programming)...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
