On Sat, Feb 12, 2011 at 8:03 PM, Dag H. Wanvik <[email protected]> wrote: > Tiago Espinha <[email protected]> writes: > >> I remember something like this as well but I also seem to remember that >> there was something "wrong" with it. If I'm not mistaken, it just throws the >> whole SQL script into one big JUnit fixture and then even if the work is >> greatly reduced, there's still an awful lot of work that has to be done >> manually. > > You are right about the fact that it puts stuff into one big JUnit > fixture. I used the converter though a while ago and it saved me a lot > of work, although I had to tweak it a lot after conversion > (OuterJoinTest, 3500 lines, DERBY-4471) with some creative Emacs > macros... > >> Personally I find that running the SQL file against the output file within a >> JUnit test is acceptable.. the test functionality is maintained and the test >> is converted into JUnit, so I'm not sure there are any significant drawbacks >> about it. > > I think part of the reason why we converted to JUnit was to make the > test assertion based. I am not sure, but I think ScriptTestCase was made > to accelerate the move away from the old test harness, not because we > wanted to continue using script output based comparisons which are more > brittle. Your call, either way, conversion to JUnit is good. > > Thanks, > Dag > > >> >> Tiago >> >> On Sat, Feb 12, 2011 at 5:11 PM, Bryan Pendleton <[email protected] >>> wrote: >> >>> \> As you'll be able to see on that >>> >>> page, SQL tests can be converted by either running the current SQL file as >>>> part of a test that extends from the >>>> util.ScriptTestCase or... alternatively... you can convert the test by >>>> hand with JDBC calls that execute the SQL commands. >>>> >>> >>> Isn't there still a tool that performs the conversion >>> from SQL script to JDBC test case automatically? You >>> still have to process the results by hand, but I recall >>> that the tool does an enormous amount of the heavy lifting >>> for you. >>> >>> I think it's called: >>> >>> org.apache.derbyTesting.functionTests.util.SQLToJUnit >>> >>> thanks, >>> >>> bryan >>> >
My 2 c: The SQLToJUnit is indeed a first step for converting .sql scripts to junit - and you'll need to do a lot of massaging. And of course it does nothing for tests that are already jave programs. We really wanted to go towards 'pure' junit conversions unless we want to test specific ij commands - which would mostly apply to tests in the 'tools' area. The scripttests were originally mostly a way to get more tests converted quicker. The trouble with the scripttests is that they're still master based, and the trouble with master based is that it's more sensitive to variations and so harder to maintain/control. (For instance, the behavior between network server and embedded runs might be different, or the behavior on different operating systems, or the behavior with different versions of the jvm.) Myrna
