I liked how easy it was to create, edit, and run the tests - hitting
refresh reloaded the test files from disk, which is a big win. I also
liked looking at the failure output in the main browser window.
I ended up putting my setup code in the common section, because it
didn't work when I put it in the setup section. Matt has a note that
setup and teardown don't work right, and I guess that is what I was
I copied some of the code from jssh's debug helper file, mostly so that
I could run the tests in both jssh and foxunit.
Changes I'd like to see:
* use files, or a hierarchy of files, instead of xml, to hold the
and paste it between the xml files and a code editor in js mode. Having
the js code in a separate file would eliminate this step.
* copy the assert function names used by xUnit test harnesses. If we
are going to have a number of test harnesses available, I'd like tests
to be as portable between them as possible.
* unattended run mode - a command-line switch that would read in a set
of tests, run them, write the results to a file, then exit. Perfect for
adding to a tinderbox test section, or other CI setup.
dev-quality mailing list
[hidden email] https://lists.mozilla.org/listinfo/dev-quality
Ew. So much for markdown looking ok in a newsgroup article. Sorry
I'm going to take a stab at writing unit tests for the next sample
extension in the article series on MDC.
I'm wondering if anyone else is interested in working on this type of thing.
I'm also going to post a few more articles here in mdq describing the
other testing tools and harnesses I've seen. Hopefully, we can have an
active discussion here and write some tests to run in these harnesses too.
> I'm wondering if anyone else is interested in working on this type of thing.
You bet :)
As you know I've been hacking testing in my part of the Mozilla world
(XForms). I have some of my "test harness" online here:
http://beaufour.dk/xftst/ There are README files that (hopefully) explains how it works. (trunk
jsunit testing is broken right now though...)