On Fri, Dec 01, 2000 at 03:55:28PM -0500, Jeremy Hylton wrote:

Is there any documentation for the Quixote unittest tool? The Example page is helpful, but it feels like there are some details that are not explained.

I don't believe we've written docs at all for internal use. What details seem to be missing? --amk

On Fri, Dec 01, 2000 at 04:21:27PM -0500, Jeremy Hylton wrote:

- I assume setup/shutdown are equivalent to setUp/tearDown

Correct.

- Is it possible to override constructor for TestScenario?

Beats me; I see no reason why you couldn't, though.

- Is there something equivalent to PyUnit self.assert_

Probably test_bool(), I guess: self.test_bool('self.run.is_draft()') asserts that self.run.is_draft() will return true. Or does self.assert_() do something more?

- What does parse_args() do? - What does run_scenarios() do? - If I have multiple scenarios, how do I get them to run?

These 3 questions are all related, really. At the bottom of our test scripts, we have the following stereotyped code: if __name__ == "__main__": (scenarios, options) = parse_args() run_scenarios (scenarios, options) parse_args() ensures consistent arguments to test scripts; -c measures code coverage, -v is verbose, etc. It also looks in the __main__ module and finds all subclasses of TestScenario, so you can do: python test_process_run.py # Runs all N scenarios python test_process_run.py ProcessRunTest # Runs all cases for 1 scenario python test_process_run.py ProcessRunTest:check_access # Runs one test case # in one scenario class --amk

...

...

...

...

"FL" == Fredrik Lundh writes:

FL> andrew kuchling wrote:

...

Someone remembered my post of 23 Nov, I see... The only other test framework I know of is the unittest.py inside Quixote, written because we thought PyUnit was kind of clunky.

FL> the pythonware teams agree -- we've been using an internal FL> reimplementation of Kent Beck's original Smalltalk work, but FL> we're switching to unittest.py. Can you provide any specifics about what you like about unittest.py (perhaps as opposed to PyUnit)? Jeremy

Hi all, Andrew Kuchling:

... I ... actually wrote some documentation for the Quixote unittest.py; please see URL:http://www.amk.ca/python/unittest.html. [...] comes out to around 290 lines; I can post it to this list if that's desired.

After reading Andrews docs, I think Quixote basically offers three additional features if compared with Tim Peters 'doctest': 1. integration of Skip Montanaro's code coverage analysis. 2. the idea of Scenario objects useful to share the setup needed to test related functions or methods of a class (same start condition). 3. Some useful functions to check whether the result returned by some test fullfills certain properties without having to be so explicite, as cut'n'paste from the interactive interpreter session would have been. As I've pointed out before in private mail to Jeremy I've used Tim Peters 'doctest.py' to accomplish all testing of Python apps in our company. In doctest each doc string is an independent unit, which starts fresh. Sometimes this leads to duplicated setup stuff, which is needed to test each method of a set of related methods from a class. This is distracting, if you intend the test cases to take their double role of being at same time useful documentational examples for the intended use of the provided API. Tim_one: Do you read this? What do you think about the idea to add something like the following two functions to 'doctest': use_module_scenario() -- imports all objects created and preserved during execution of the module doc string examples. use_class_scenario() -- imports all objects created and preserved during the execution of doc string examples of a class. Only allowed in doc string examples of methods. This would allow easily to provide the same setup scenario to a group of related test cases. AFAI understand doctest handles test-shutdown automatically, iff the doc string test examples leave no persistent resources behind. Regards, Peter

Hi, everyone. A potential customer has asked whether there are any plans to re-organize and rationalize the Python standard library. If there are any firms plans, and a schedule (however tentative), I'd be grateful for a pointer.

Alas, none that I know of except the ineffable Python 3000 schedule. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)