I might be about to wander into a crevasse of over-engineering. Your opinions are requested.
The problem of the day: run the tests for all of the tests we want to run. Discover "all of the tests we want to run" implicitly; to add a test, all the programmer needs to do is write the test -- not add the test to a list of files. Other goals: * the tests should run "fast." * the test harness should be maintainable. * the test harness should use the same machinery on all OS's and runtimes as much as possible. * the test harness should not add to the already-complex development environment setup. Our current approach to the unit test harness involves two pieces that I'd like to eliminate: - runlzunit.sh, a somewhat obfuscated shell script with case statements for cygwin/mac/linux - a hand-edited list of tests - separate invocations of firefox for each test. when extended to the rhino runtime, this would be separate invocations of java for each test, which is ouch. I'm using the dojo tools for unit testing. This particular part, though, I don't like dojo's solution: there's an ant task which invokes a python script to generate a list of tests; those tests are then executed in rhino, where rhino is run as java in a separate vm. All of this has me looking longingly at JUnit. I'm thinking of writing a JUnit extension which... - finds all the tests to run using JUnit built-in behavior, either batchtest or ant's fileset - executes JUnit and rhino within a single jvm, the same one used by ant. - uses JUnit's reports, which include plaintext and xml output - uses pure java instead of a shell script (current openlaszlo solution) or python (current dojo solution) Overengineered? Or just engineered enough? Simpler ideas gratefully accepted. benjamin shine software engineer [EMAIL PROTECTED] _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
