From: "Michael Foord" <fuzzyman@voidspace.org.uk>
However, to provide readable output for errors in even simple tests (like a == b) py.test does magic with stack frames and code objects - in order to discover the objects being compared.
Don't have to go that route. Can use plain python assert failures with a stacktrace. Or can trigger pdb, or let the user specify a mode that calls some more advanced test runner or test reporter with introspection. This can be done without making everything hard.
I think it would be a bad idea to move *Python testing* itself over to a framework like this.
Don't want to convert the python testing. Would like to offer a lighter-weight alternative to our users.
I personally find unittest pretty readable, the feature most lacking is autodiscovery of tests which nose does seem to provide very well although I haven't used it yet.
It takes about one day of using py.test to realize have much cleaner and more readable its syntax is. Also, writing the tests is *much* more pleasant. It has the same clean, clear joy as writing regular python code. By comparison, the code using unittest.py is javaesque. I've written tons of test with unittest.py and and find it to be joyless. I realize there is a matter of taste involved but if you talk to any regular users of py.test, they will *all* attest to the syntax being much more readable, lightweight, and pleasant to use. It encourages writing tests. That being said, I think there are less magical, much simpler ways to implement it. I think Holger is working on it as we speak. Raymond