[TIP] Test functions with unittest2, reprise: philosophy

[J. Cliff Dyer]

On Fri, 2010-03-05 at 11:27 -0500, Victoria G. Laidler wrote:
> Hi Michael,
> 
> Yesterday you sent an example of how to use test functions with 
> unittest2, and also stated that you don't plan to make this capability 
> natively available. I'd like to understand your reasoning, and explain 
> why I think it should be.
> 
> Unittest is the de facto standard of how to do testing in python, 
> because it's in the stdlib. One of the great strengths of python, IMHO, 
> is that it allows people to write either OO or procedural code, so 
> developers can use the approach that best matches either the problem 
> domain or their own skillset/preferences. It therefore seems to me like 
> a real lack in the de facto standard to support an OO approach to 
> testing, but not a function-based approach. If the code I'm testing is 
> not OO, then forcing me to write my tests in an OO fashion forces me 
> through an additional level of abstraction away from what I'm actually 
> trying to do.
> 

The above argument doesn't make sense to me.  It is no harder to write
test classes for non object oriented code than it is to write test
classes for object oriented code.  Similarly object oriented code can
just a simply be tested with function-based tests.  The coding style of
the tests does not cause any impedance mismatch with the code.

> Secondly, it seems to me that as "testing evangelists", we should be 
> trying to make the
> entry barrier to testing as low as possible. One of the things I liked 
> about unittest when I first encountered it is that I could figure out 
> how to write and run tests without really understanding how it all 
> worked. I couldn't make test suites, I couldn't make test runners, or 
> loaders, or any of that other fancy stuff, but that was OK - I didn't 
> really care how unittest worked, I just wanted to write tests for my 
> software and run them, and that much I could figure out how to do as 
> soon as I wrapped my brain around an object-oriented approach to testing.
> 

This is a slightly better argument.  Testing should be easy and fun, and
if function-based tests are easier and more fun, why not support them in
the stdlib testing library.  However, I'm not sure why you're worried
about loaders now.  The same code you used to write for the old unittest
still works now.  You don't need to worry about loaders, runners and
test suites any more now than you did then.

> The "simpletest" module that you sent around fails that level of utter 
> simplicity, because it requires me to think about "loading tests", which 
> I otherwise don't have to think about. I don't want to have to think 
> about how unittest works when I'm writing tests: I want it to "just work". 
> 

> I also don't want to have to figure out a place for simpletest.py to 
> live so it's always available whenever my tests might be run, and drop 
> this extra line  at the bottom of every file that contains test 
> functions. In the language of "batteries included", this is just a 
> different size battery, so why isn't it included?
> 

> I look forward to hearing your reasoning about this issue.
> 
> thanks,
> Vicki
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>