[TIP] Test functions with unittest2, reprise: philosophy

[Michael Foord]

On 05/03/2010 16:27, 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.
>
> 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.

So if unittest based testing is already so easy there is no need for an 
alternative approach then. :-)

To be honest I've had this same conversation quite a few times and, no 
disrespect to yourself, am getting a little bored of it. I don't 
particularly want to get drawn into a long debate, so please forgive me 
if this is my last reply on this particular topic.

There are several issues. Here are some of them:

* For any non-trivial testing scenario an object oriented approach is 
usually the right level of abstraction. It is for these scenarios that 
unittest is designed. Testing can certainly be done in other ways - and 
I have no problem with other tools being used for those techniques. 
unittest does *not* intend to be a jack-of-all-trades. It does intend to 
be flexible enough for other people to build interesting things on top 
of - as my email was trying to demonstrate.

* Many of the other Python-devs don't like / aren't convinced by a 
function based approach so it would likely never get in *anyway*.

* It would extend the unittest API a great deal.

* unittest is opinionated about how you should do testing, and an object 
oriented approach is what it thinks you should be doing.

>
> 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?
>
pip install simpletest # doesn't work yet naturally

Then copy and paste a single line into the bottom of your test modules, 
don't worry about what it does. (If you're using the test functions 
you'll already have the import so it really would be a single line).

I don't see those two steps as a big barrier. If you disagree, writing a 
discovering test loader that extends the unittest2 TestLoader but 
incorporates this functionality is *also* trivially easy, and is left as 
an exercise for the reader.


Doubting-I've-heard-the-last-of-this'ly y'rs,

Michael


> I look forward to hearing your reasoning about this issue.
>
> thanks,
> Vicki


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.