ANN: pry unit testing framework

[Aldo Cortesi]

Thus spake Kay Schluehr (kay.schluehr at gmx.net):

> But you could have added the integration of code coverage and other
> helpful features with unittest as a conservative extension giving
> everyone a chance to use it directly with existing tests instead of
> forcing them to rewrite their tests for bike shading purposes.

You're assuming that Pry's only purpose is to introduce test coverage.
This is not the case - I already had a module that largely maintained
unittest compatibility, but added a command-line interface and coverage
analysis. It's now obsolete, but you can find its remains here if
you're interested:

http://dev.nullcube.com/gitweb/?p=pylid;a=shortlog

So, why did I re-write it? Well, I needed a test framework that didn't
have the deep flaws that unittest has. I needed good hierarchical
fixture management. I needed something that didn't instantiate test
suites automatically, freeing me to use inheritance more naturally
within my test suites. I needed more sophisticated handling and
reporting of errors during startup and teardown. I needed better
support for programmatic generation of tests. The list goes on.  Pry
has all of this, and much of it is simply not possible while
maintaining backwards compatibility.

Yes, test coverage is critical and hugely neglected by most people, but
Pry addresses other problems as well. We're not "forcing" anyone to
rewrite anything, but if the description above sounds like something
you want, maybe you should give Pry another look. If Pry itself is not
to your taste, there are other excellent test frameworks like py.test
that have also chosen not to mindlessly duplicate all of unittest's
inadequacies. Broaden your horizons and explore some of these - your
code will thank you for it...





Regards,



Aldo


-- 
Aldo Cortesi
M: +61 419 492 863
P: +61 1300 887 007
W: www.nullcube.com