Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Sunday April 13, 2003
03:24 PM

Testing Python

[ #11628 ]

Once again, I'm playing with another language. This time, I decided to put a fair amount of effort into learning Python. After returning the book I bought two days ago after discovering it was out of date, I simply grabbed the latest docs from the Python site and decided to sit down and start coding. Naturally, the first thing I wanted to do was learn how to write tests. I watched how our Python programmer at work wrote tests and I was surprised at how much code he had to write for it, so I started searching for Python testing frameworks myself. That's when I discovered Python's unittest. Here's how to write two tests:

import unittest

class SimpleWidgetTestCase(unittest.TestCase):
    def setUp(self):
        self.widget = Widget("The widget")

class DefaultWidgetSizeTestCase(SimpleWidgetTestCase):
    def runTest(self):
        self.failUnless(self.widget.size() == (50,50),
                        'incorrect default size')

class WidgetResizeTestCase(SimpleWidgetTestCase):
    def runTest(self):
        self.failUnless(self.widget.size() == (100,150),
                        'wrong size after resize')

It appears that for each test case, I have to define a new class and then run tests on it. I'm totally blown away by the amount of work involved and all I want to do is write simple tests. While I realize that I might be reinventing the wheel, I decided that a great way to learn Python would be to write my own testing framework modelled after Perl's Test::More.

import mytest
import Widget
t = mytest.test(count = 2)
widget = Widget("The widget)
t.match(widget.size(), (50,50),
        name="Default size should be correct")
t.match(widget.size(), (100,50),
        name="... and resize should work")

That would produce output like:

1 .. 2
ok 1 - Default size should be correct
ok 2 - ... and resize should work


Success: 2
Failure: 0
Percent passed: 100.00

So far, that's much more like what I'm used to seeing and it was pretty easy to implement (though I have a lot of work to do). However, as I get further into Python, I can only assume that they have reasons for why they're doing things their way. I don't understand why they lack test counts, for example. Perhaps procedural tests (even if implemented through an object instance) simply don't fit the Python model very well, but we'll see what happens.

And for my first actual test program:

import test

t = test.test(count=4)

t.ok(1, name='1 should be true')
t.match(2,2,name="2 should equal 2")
t.no_match(2,3, name="two should not equal three")
t.match(2,3, name="two should not equal three")
t.ok(not None, name="'None' should evaluate as false")

I get the following results:

1 .. 4
ok 1 - 1 should be true
ok 2 - 2 should equal 2
ok 3 - two should not equal three
not ok 4 - two should not equal three
        Expected: (2)
        Got:      (3)
ok 5 - No test name assigned
ok 6 - 'None' should evaluate as false


Dubious test results. 4 tests requested and 6 tests ran
Success: 5
Failure: 1
Percent passed: 83.33

Next I need to add many more testing methods and try my hand at producing a test harness. I may very well scrap all of this in the end but it's a great learning experience.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Hmm... (Score:3, Interesting)

    by pdcawley (485) on 2003.04.13 15:46 (#19075) Homepage Journal
    Hmm... a quick look at the PyUnit home page (it's on sourceforge) implies that you don't need a class per test, you just have to make sure that all the tests you want to run with a given fixture (set up using the setUp method) match /^test/, which is very much in keeping with the original sunit way of doing things.

    It's worth persevering with as a testing framework, honest. Once you get the hang of it, you'll find something like it for almost every OO language you care to think about.
    • Ah, that has better testing information that the docs that I grabbed. Looks like it's fairly useful. Thanks!

  • It is the normal structure of the xUnit based test frameworks. I use Nunit (.NET unit testing) at work.

    But it is better than nothing. I still need to convince all my colleagues of the necessity of writing unit-tests.

    And I think you can easily build a lighter framework with the building blocks provided xUnit based framework.

    BTW: there is a xUnit framework for Perl aswell, check perlUnit also at sourceforge.
    • Speaking as someone who used to be the maintainer of this package, I've switched to using Test::Unit, which place nicely with all the other testing frameworks that are built on top of Test::Builder. It does a few things different if you're used to the xUnit way of things, but I find it to be a really good synthesis of approaches.