unittest vs py.test?
Roy Smith
roy at panix.com
Sun Apr 3 08:37:01 EDT 2005
In article <7x3bu8t7or.fsf at ruckus.brouhaha.com>,
Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
> "Raymond Hettinger" <vze4rx4y at verizon.net> writes:
> > When writing a large suite, you quick come to appreciate being able
> > to use assert statements with regular comparision operators, debugging
> > with normal print statements, and not writing self.assertEqual over and
> > over again. The generative tests are especially nice.
>
> But assert statements vanish when you turn on the optimizer. If
> you're going to run your application with the optimizer turned on, I
> certainly hope you run your regression tests with the optimizer on.
That's an interesting thought. In something like C++, I would never think
of shipping anything other than the exact binary I had tested ("test what
you ship, ship what you test"). It's relatively common for turning on
optimization to break something in mysterious ways in C or C++. This is
both because many compilers have buggy optimizers, and because many
programmers are sloppy about depending on uninitialized values.
But, with something like Python (i.e. high-level interpreter), I've always
assumed that turning optimization on or off would be a much safer
operation. It never would have occurred to me that I would need to test
with optimization turned on and off. Is my faith in optimization misguided?
Of course, all of the Python I write is for internal use; I haven't yet
been able to convince an employer that we should be shipping Python to
customers.
More information about the Python-list
mailing list