Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.
— M.A. Jackson
"More computing sins are committed in the name of efficiency (without
necessarily
achieving it) than for any other single reason - including blind
stupidity."
— W.A. Wulf
"We should forget about small efficiencies, say about 97% of the
time: premature
optimization is the root of all evil."
— Donald Knuth
"The best is the enemy of the good."
— Voltaire
c.f, my talk ["A Software Journeyman on a Panel of Wizards"](http://
pt.withy.org/publications/Runtime.pdf)
On 2006-04-02 20:51 EDT, Benjamin Shine wrote:
>
> Someone once said, "first make it work, then make it fast." (Mostly
> attributed to Knuth.) I'm getting hung up on iterating across
> multiple test files, but we actually already have that working, just
> not as prettily as I'd like, with runlzunit.sh.
>
> We need a suite of working tests _now_. Optimizations with using a
> single JVM are theoretically possible, and clever javascript or java
> test discovery is possible; for now I should move my focus away from
> those issues, and focus on parts of the test harness that don't exist
> at all yet.
>
> That "next important part" is, "so what does an lzx test using on
> dojo/jum actually look like?" with an initial focus on the tests
> Henry and Jim named.
>
> On Apr 2, 2006, at 12:26 PM, Benjamin Shine wrote:
>
>>
>> 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
>
> benjamin shine
> software engineer
> [EMAIL PROTECTED]
>
>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
