[TIP] Doctest or unitest?

[Michael Foord]

Jim Fulton wrote:
> On Mar 3, 2007, at 12:29 PM, Grig Gheorghiu wrote:
>
>   
>> This is the question that Michael Foord asks in his latest blog post:
>>
>> http://www.voidspace.org.uk/python/weblog/ 
>> arch_d7_2007_03_03.shtml#e652
>>     
>
> I commented on this.
>
>   
>> To me, they represent 2 different styles of testing: procedural
>> (unittest) vs. declarative (doctest).
>>     
>
> I don't see doctests as particularly declarative.
>
> For me, the two styles are: "framework heavy" vs "example based".
>
> I sometimes refer to the former as "javiotic". :)
>
>
>   

I guess I'm pretty comfortable with unittest, so perhaps I'm just being 
complacent... *but* once you have a framework in place then there need 
be precious little sign of it actually in your tests.

And then calls like 'assertEquals', 'assertIn' etc - tend to be very 
readable indicators of what you're testing.

I find doctests 'visually noisy' (littered with '>>>' and '...') and 
because they're inside strings you lose the help of your IDE when 
writing them.

For executable examples doctests are great, but they just plain don't 
make sense to me when writing extensive tests. I accept that this is 
*completely* a matter of taste though.


>> I had an aha-type moment during
>> PyCon when I realized that both Fit/Fitnesse and doctest are very
>> similar in that they represent 'example-driven testing' (I didn't
>> invent the term example-driven, Brian Marick did). You specify inputs
>> with expected outputs, in the form of examples.
>>     
>
> Yes.
>
> I'll add that they also support a style of development that I call  
> "documentation driven".  If done well. this encourages you to  
> document how the user will use your library or application to achieve  
> their goals. I find that this viewpoint allows problems in interfaces  
> (API or user) to be discovered or avoided early.
>
>   

I've not 'got' Fitnesse yet - something I need to look into.

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml