[Twisted-Python] Trial - A replacement for pyunit.
Announcing "Trial". In the spirit of "We Invented NIH", Twisted Matrix Labs bring you a replacement for your favourite unit test framework. So what's my excuse? Twisted has already forked pyunit, so in a sense this is nothing new. However, changes made to that forked code-base aren't really that useful to any of our users. To get any of our added value, they'd have to use their own fork of pyunit. Re-writing it gets rid of any nasty copyright issues. Asynchronous unit tests are a challenge. The DeferredTestCase stuff in pyunit.unittest is a start, but not enough. Hopefully, trial will make it easier. The tight coupling of runtests and test_all is kind of ugly. This is no longer necessary in trial. $ ./admin/runtests -t is equivalent to $ ./bin/trial -p twisted.test Oh, I should mention that this wasn't my idea. It's all glyph's fault. He made me do it. cheers, jml
On Fri, 2003-01-03 at 23:35, Jonathan Lange wrote:
Announcing "Trial".
CVS HEAD now uses trial. admin/runtests has been updated. It's been tested with python 2.1 and 2.2 on debian linux. It's almost exactly like pyunit in api. Where you did from twisted.trial import unittest now do: from pyunit import unittest Similarly class MyTest(unittest.TestCase): def __init__(self, method='runTests'): unittest.TestCase.__init__(method) # ... becomes class MyTest(unittest.TestCase): def __init__(self): # ... TODO (maybe): - Add recursive search option (for -p) - Fancy GUI - Yummy async features. - Randomize execution order - Option to repeat tests n times. - Incorporate warner's reactor cleaning patches - Web reporter. jml
On Sun, Jan 05, 2003 at 02:11:30PM +1100, Jonathan Lange wrote:
On Fri, 2003-01-03 at 23:35, Jonathan Lange wrote:
Announcing "Trial".
TODO (maybe): ... - Randomize execution order
Thought of something. When this is implemented, it'll be very important (for obvious reasons) to have the execution order saved to some file on every run, with the ability to read in that file for future runs. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://twistedmatrix.com/users/radix.twistd/
On Sun, Jan 05, 2003 at 03:45:39AM -0500, Christopher Armstrong wrote:
TODO (maybe): ... - Randomize execution order
Thought of something.
When this is implemented, it'll be very important (for obvious reasons) to have the execution order saved to some file on every run, with the ability to read in that file for future runs.
Maybe just print out the PRNG seed you started with when exiting. -- :(){ :|:&};:
On Mon, Jan 06, 2003 at 06:06:08AM +0200, Tommi Virtanen wrote:
On Sun, Jan 05, 2003 at 03:45:39AM -0500, Christopher Armstrong wrote:
TODO (maybe): ... - Randomize execution order
Thought of something.
When this is implemented, it'll be very important (for obvious reasons) to have the execution order saved to some file on every run, with the ability to read in that file for future runs.
Maybe just print out the PRNG seed you started with when exiting.
Hmm. While Python's PRNG is pure python, so should give the same results with the same seed on different platforms, I think saving the execution order is better. Consider the case of fixing a test that involves generating more or less random numbers than before -- the act of fixing the test loses the determinism you were hoping to preserve with the PRNG. Also, it'd probably be nice if adding tests didn't interfere with "replaying" a specific run of tests. It's probably worth saving the PRNG with the execution order, though :) -Andrew.
On Mon, Jan 06, 2003 at 05:34:17PM +1100, Andrew Bennetts wrote:
On Mon, Jan 06, 2003 at 06:06:08AM +0200, Tommi Virtanen wrote:
On Sun, Jan 05, 2003 at 03:45:39AM -0500, Christopher Armstrong wrote:
TODO (maybe): ... - Randomize execution order
Thought of something.
When this is implemented, it'll be very important (for obvious reasons) to have the execution order saved to some file on every run, with the ability to read in that file for future runs.
Maybe just print out the PRNG seed you started with when exiting.
Hmm. While Python's PRNG is pure python, so should give the same results with the same seed on different platforms, I think saving the execution order is better. Consider the case of fixing a test that involves generating more or less random numbers than before -- the act of fixing the test loses the determinism you were hoping to preserve with the PRNG.
You could create a new Random object that is used exclusively by the test framework. Calls to its generation functions won't be interferred with by calls to the "regular" functions, nor will it interfere with them. I think just saving the seed is a little cleaner and, imho, the unit tests already leave far too much garbage lying around on the filesystem as it is ;) Jp -- Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1.5 tons. -- Popular Mechanics, March 1949 -- 12:00am up 21 days, 9:46, 1 user, load average: 0.04, 0.11, 0.16
participants (6)
-
Andrew Bennetts -
Christopher Armstrong -
Jonathan Lange -
Jonathan Lange -
Jp Calderone -
Tommi Virtanen