On 08/12/13 10:22, Rafael Knuth wrote:
My understanding of unit testing is that I have to embed my code into
a test and then I have to define conditions under which my code is
supposed to fail and pass. Is that assumption correct?
That's correct for any kind of unit testing, not just using the
unittest module. Others have shown how to get started with it.
Here are some things to think about when testing.
If you have input parameters that are collections, say a list, then
always test how the function reacts to an empty list, or a different
type of collection, say a tuple, or a list of data other than the
expected type (say you expect a list of numbers and get strings
instead). And a very large list(some function use recursion
which can break with large data sets) In other words think of
what somebody else using your function might to do it that
could break it.
Similarly with numbers that, say, act as indexes into a list.
Check for negative numbers, zero, small positive numbers,
large numbers, floats, non-numbers
Hopefully that gives some idea of the kinds of things you should
test for. In a real-world project the test code is often bigger
(sometime much bigger) than the code being tested (although also
much more repetitive!).
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
