On Sun, 2010-08-01 at 03:30 -0400, Huy Ton That wrote:
> Hi all,
>
> Do any of you have any feedback, strategies and best practices related
> to unit testing within Python. This is a relatively new topic for me.
> I was thinking of starting with reading the documentation associate
> with the unittest module.
My answer falls in the category "feedback" (I was also going to mention
the diveintopython page, but somebody else has done that already!), so
you should be aware what follows is highly subjective...
JUST THINK... IN PYTHON!
IMO, unit testing is really easy to pick up. It really does not
amount to much more than taking note (in python) of what you are
thinking when you are coding.
If you are anything like me, when you code you keep on formulating
"rules" in your head, in the line of "when everything works as expected,
if the methods iterates four times, then this method must return X" or
"when everything works as expected, if a user enter a value over 212
then the script must throw this exception", etc...
* the "when everything works as expected" translates in "this test
pass when..."
* the "if X" translates in your test case (i.e. the scenario you are
testing for)
* the "then Y" translates in "the outcome of my test case must be Y"
TESTING IS VALUABLE IN THE LONG RUN
At times, designing and coding a test is a time-consuming activity,
and if the code is particularly straightforward you might be tempted to
skip the unit testing altogether. In my experience - however - unit
testing is never as useful on the spot as it is three months from now,
when you will have/want/choose to modify a little bit of your old code,
and all of a sudden everything will break. In the latter scenario, your
test suite will be an invaluable asset.
FUNCTIONAL PROGRAMMING WINS
The most difficult thing in writing a test, is replicating the state
of the environment needed for the test to happen. This is especially
(but not uniquely) true for DB-driven applications, when you might wish
to perform test on methods that interact with the DB. In that case you
have to create a test DB, populate it with ~credible data, etc...
The most "functional" (as in functional programming, i.e.
machine-state independent) is your code, the easiest is to write a test.
Example: if you need to check a method that validate the postal code of
an address based on the name of the city, it is easier to test a method
that is invoked with "validate_postal_code(code, city)" rather than one
that is invoked with "validate_postal_address(user)" and that will have
to retrieve the full address of a user from a DB, and extract the city
and postal address from it.
MVC WINS
I never test UI's. I know it is bad... but it is simply too
time-consuming for me (I'll be very glad if somebody reading this will
show me how one can make it snappier!). This means - at least for me -
that writing tests become extremely easier for me if I keep separated
the presentation layer from all the rest of the stuff.
EVERY BUG IS A TEST YET NOT WRITTEN
A program that passes all its tests is not necessarily a bug-free
program. But once you find a new bug, try to make a point of writing a
new test that check for that particular scenario in which said bug is
happening.
TEST-DRIVEN IS BETTER
What I find useful (although not always applicable) is to start my
programming session by writing the tests before I write the code to be
tested. This somehow reconnect to my previously articulated "just
think... in python!" point: you are however *already doing a list of
rules* in your head, before writing code, so you could well write it
down directly in code. All you need is to create a mock method/function
in your code with the same signature you are using in your test. For
example. You could write tests in the form:
assertEqual(better_square_root(9), 3)
assertRaises(ValueError, better_square_root, -4)
and then write in your module:
def my_better_square_root(number):
pass
all your tests will of course initially fail, but then you will keep on
working on the code of my_better_square_root until all your tests pass.
Well, these are just my two ยข... As stated in the beginning: highly
subjective, so keep your mind open for other (possibly opposite)
opinions too! :)
HTH,
Mac.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
