[
https://issues.apache.org/jira/browse/DERBY-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew McIntyre updated DERBY-2151:
-----------------------------------
Attachment: derby-2151-andrew-v1.diff
I figured I could use this to convert grantRevokeDDL/grantRevokeDDL2, so I took
Army's original utility (thanks, Army!) and made a few alterations to account
for multiple user connections among other things. I wasn't aiming for anything
close to perfection, so I stopped when I got it to convert > 99% of the SQL in
grantRevokeDDL and grantRevokeDDL2. I also put it into the functiontests.util
package, so that it would compile easily with the current build setup.
Attaching the updated utility, also renamed to SQLToJunit, as a diff.
The newer version actually converts simpler tests more poorly than the original
version, mostly because ij sometimes doesn't print a row count out for queries.
It seems like it would be easy to hold on to a line in the rewritten
getNextIjCommand() and simply push that into the buffer on the next call if the
we read one too many lines and get a comment or command.
If I have some time I'll look into fixing it up a bit more to handle a broader
range of cases. It seems like in the future it might be useful for easily
converting SQL provided by users into reusable JUnit testcases.
> "Fixer-upper" utility to help convert ij canon-based tests to JUnit.
> --------------------------------------------------------------------
>
> Key: DERBY-2151
> URL: https://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: derby-2151-andrew-v1.diff, 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.
-
You can reply to this email to add a comment to the issue online.
