[Chandler-dev] Script-recording/playback as test framework
Mikeal Rogers
mikeal at osafoundation.org
Tue Dec 26 17:36:57 PST 2006
> Personally, I'd vote against both asserts (which don't fire if
> you're running optimized, as we'd want for the performance tests)
> and the previous pass/fail approach (which is baroque and error-
> prone). Instead, why not have tests inherit from unittest.TestCase,
> since:
I'm not against integrating with unittest, but I'm hesitant to use
unittest _every_ time we run a script. One thing I forgot to mention
was that we plan on adding a submenu in test, that has a list of all
the standard tests we have written, that can be run at any time. A
big difference with the new test approach is that we're using one
feature, script recording/playback, for a few different facilities.
If someone records a script and plays it back, they don't necessarily
want to run a "test", they could just be automating some piece of
their workflow.
> 1) That has a pretty expressive API for validating state
> (TestCase.failUnless, TestCase.failUnlessEqual, etc)
> 2) Tests that depend on setting up shared data can use inheritance,
> usually in conjunction with setUp() methods.
With the way we have things now we're trying to keep people from
needing to write code to get a test going. In this case how do we
even handle tests that use shared data? This may be a feature we want
to build for continuous integration (tinderbox) that's outside of the
regular script recording/playback.
> 3) Less wheel reinvention, less having developers have to learn new
> APIs.
So there shouldn't be any api learning for people writing tests,
because writing tests shouldn't require any code writing. The script
recorder will output a test a file with a "run" method that contains
everything needed to run the test.
I think for the continuous integration case (tinderbox) we'll need to
run the tests a bit differently that we do when selecting them from a
file or menu as the case is now. A good idea would be to write a
TestLoader class that pulls all the test methods in from all the
files we've saved in script-recording and assigns them as methods in
TestCase clases so that we can run the full test suite in unittest.
-Mikeal
More information about the chandler-dev
mailing list