db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2151) "Fixer-upper" utility to help convert ij canon-based tests to JUnit.
Date Tue, 05 Dec 2006 17:48:21 GMT
     [ 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.



> 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...

> "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:
>            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


View raw message