[Laszlo-dev] LzUnit modification proposal
P T Withington
ptw at pobox.com
Thu Jul 14 08:57:15 PDT 2005
Well, I wrote lzunit. It is mostly written in LZX, although there is
a fair amount of scripting. I tried to model it very closely on
That doesn't seem to have any provision for asynchronous tests. If
there were some pattern already out there for dealing with
asynchronous tests, I'd prefer to follow that rather than invent our
own. (I also wrote it quite a while ago, so it probably is not the
best example of good LZX style.)
What you propose should be doable. If you look at the
lzunit.runNextTest method, you will see that it simply queues itself
up to run the tests, one at a time, in the idle loop. This is
necessary because the Flash player will complain if you run too long
in the foreground (of course, if you run too long in the idle loop,
you will just be silently terminated). It would be fairly easy to
change the runtNextTest method to not requeue itself in the case of
an asynchronous test (and to queue a timeout instead). When you test
completes, or the timeout happens, you can invoke runNextTest to pick
up with the next test.
I'd be interested in comments on your proposed interface, or to know
if there are existing *unit mechanisms for asynchronous tests we
should be emulating.
On 11 Jul 2005, at 17:49, Benjamin Cox wrote:
> The process of writing and maintaining any kind of serious unit
> tests in Laszlo is significantly hampered by the fact that the
> assertion of the results of time-consuming, asynchronous operations
> can't be guaranteed to be made before the suite runs the next
> testXXX method.
> I'd like to propose a fairly simple addition to the LzUnit
> process... I'd like to see TestCase contain some mechanism for
> signifying that a test is not yet complete.
> For example:
> <method name="testSomething">
> this.assertDelegate = new LzDelegate(this, "assertSomething");
> LzTimer.addTimer(assertDelegate, 500);
> setTestRunning(true); // This sets the flag
> which causes the next test not to fire when this one returns.
> <method name="assertSomething">
> assertEquals(100, classundertest.width);
> setTestRunning(false); // So you just have to
> remember to set it back in your assertion!
> If setTestRunning(true) has been called when the testSomething()
> method returns, the testsuite thread that runs the testXXX methods
> would pause until setTestRunning(false) is called. At that time,
> it would notice and proceed with the next test.
> Some form of timeout would likely need to exist, as well, in case
> the setTestRunning(false) is never called (either forgotten in the
> assertSomething() method, or if the test failed and never called
> the assertSomething() delegate). This could be global, like the
> asynchronoustests flag, or perhaps another method call or property
> of TestCase, if you wish to change it from the default.
> Does this seem like a good idea to others? Has anyone really
> gotten very deep with LzUnit: enough so to have another suggestion
> for dealing with this? My current approach is to call setUp();
> doTestSomethingElse(); tearDown() in my assertSomething() method,
> which is pretty hackish if you ask me ;-)
> I really haven't looked deeply at internal Laszlo code whose
> filenames don't end in .lzx. What would it take to do #2 as I've
> described? I'd gladly do the doing if pointed toward the relevant
> files... unless someone else "owns" this code.
> Thanks much,
> co+optual (www.cooptual.com)
> Ben Cox
> Chief Technologist
> "Reality is that which, when you stop believing in it, does not go
> away." - Philip K. Dick
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
More information about the Laszlo-dev