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
test_*.py, and define a function that starts
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.