Thanks additionally for your insight gems. Without reading too much into it, it was quite simple to create a series of test classes which just run some expected assertion values on a small scenario of inputs and what's expected.
I usually find that I learn best by dabbling around in source code, then writing some code to test what I think I know. I'll try to integrate this and commit this to memory with time where I won't have to look back as much (: On Sun, Aug 1, 2010 at 9:25 AM, Mac Ryan <quasipe...@gmail.com> wrote: > 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
