Thus spake Roy Smith ([EMAIL PROTECTED]): > I've been following this thread for a while with a mix of amusement and > alarm. Contributing code to the community is a good thing, and should be > celebrated. If people like it, they will use it. If they don't, it will > be ignored. None of which justifies the hostility this thread seems to > have degenerated into.
I agree entirely - I've been astonished by the whole fracas myself. I'm offering Pry simply as something neat I wrote that other people might find useful, no more. > In any case, I don't understand why you say that unittest doesn't use > "assertion-based testing". They seem like assertions to me. What am > I missing? While you can use the built-in "assert" statement in unittest tests, it turns out to be annoying in practice, especially during rapid code-test-code iterations. The problem is that assert traceback errors are uninformative - when "assert a == b()" fails, there's no way to tell what a and b() were in this context. Unittest copes with this with convenience methods - instead you write self.assertEqual(a, b()), which then gives you proper error reporting. I think it was py.test that first introduced some magic that picks up the AssertionError traceback, parses the original expression, and then re-evaluates its components to give you an error featuring the "disassembled" assertion expression. This approach has been adopted by nose and independently by pry. While re-evaluation has some limitations (like not dealing well with expressions that change state), using assertions makes for more fluid and natural expression in tests. Maybe "assertion-based" is not an exact phrase to describe this - saying that these frameworks support "expanded error reporting for Python assert statements" might be more accurate. Regards, Aldo -- Aldo Cortesi M: +61 419 492 863 P: +61 1300 887 007 W: www.nullcube.com -- http://mail.python.org/mailman/listinfo/python-list
