I came upon py.test a while ago, via Jarno Virtanen (though py was named std back then). I've always disliked unittest. I created an alternate test runner based on unittest -- DataTest - but never felt great about it. OK, but not great.
Anyway, py.test has a philosophy that appeals to me: the best API is
no API. And for the most part that's it. You can read some more
about the hooks and functions in the
documentation, but you don't need them to do your work. All you need to do is
create a module
test_*.py, and define a function that
test_. py.test will automatically run it,
and any other test-looking functions it finds, and report on any
errors. This isn't complicated, but I still have no idea how to do
it with unittest, and it's not for lack of trying. (OK, I knew how
to do it, but it never felt right and now I've forgotten, which
means it never made sense to me either.) So a test might look like:
import roman def test_sanity(): for i in range(1, 4000): assert roman.fromRoman(roman.toRoman(i)) == i
You can structure your tests as classes as well, and do startup and
teardown methods and functions, but you don't have to. And you can
assert, as it has fancy tracebacks; when an
assert fails it (re) evaluates every subexpression and displays them
all, so you'll see all the values you are interested in.
It has a number of other features as well. Probably the one I'm most interested in is it's still under development. Unittest was a port of a Java project (which was a port of a Smalltalk project), and it just kind of appeared. It's never fit into Python well. For something so important, there needs to be a real feedback cycle, and continued development in response to people's needs. Testing should be easy, and this is the first testing framework that's really as easy as I think it should be. Well, doctest is also very easy and cool; py.test makes all unit testing feel like doctest.
In other doctest news, Phillip writes about doctest, and I notice there's some features in doctest in 2.4 that I had wanted.