Art of Unit Testing

[robin and jim]

"Paul Moore" <paul.moore at uk.origin-it.com> wrote in message
news:q36qnto1nrrvkch2a3b7ck0e657iaoma8d at 4ax.com...
> On Fri, 17 Aug 2001 10:00:46 +0200, Boudewijn Rempt
<boudewijn at tryllian.com>
> wrote:
>
> >I've found little value in writing unittests for GUI apps (and that
> >includes games), but lots of use for unittests in the underlying
libraries.
>
> One thing that I've not seen pointed out anywhere (it doesn't even seem to
be
> in the manual!) is that to write simple tests is pretty much trivial:
>
> import unittest
>
> class Tests(unittest.TestCase):
>     def test1(self):
>         self.assertEquals(1,1)
>     def test2(self):
>         self.assertEquals(1,2)
>
> if __name__=='__main__':
>     unittest.main()
>
> Basically, it looks like unittest.main() scans the code for classes
derived
> from unittest.TestCase, and runs all methods whose names start with 'test'
as
> test cases.
>
> This makes writing a series of simple, repetitive, tests very
straightforward.
> Obviously, for more complex cases, you need the more complex
infrastructure,
> but I have to say that *not* emphasising how simple it is to write basic
> tests, does put people off. (It certainly put me off!)
>
> One point with this form of test: If I add a setUp() or a tearDown()
method,
> they are called before and after *each* test, rather than once at the
start
> and end of the suite of tests. But without this stuff being documented,
I'm
> not sure if this should be considered "correct"...
>
> Paul.
>
>
You are quite correct (according to my version of the documentation -- and
in my experience with using the tool); setUp and tearDown are called for
each test so you always start and end from a known state. <wink>