[Tutor] Where to start with Unit Testing

[Huy Ton That]

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 <quasipedia at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20100802/3875ce2e/attachment.html>