471,579 Members | 1,472 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,579 software developers and data experts.

unittest setup

hi all,

I noticed that setUp() and tearDown() is run before and after *earch*
test* method in my TestCase subclasses. I'd like to run them *once* for
each TestCase subclass. How do I do that.

thanks
paul

Sep 25 '05 #1
5 3191
paul kölle wrote:
hi all,

I noticed that setUp() and tearDown() is run before and after *earch*
test* method in my TestCase subclasses. I'd like to run them *once* for
each TestCase subclass. How do I do that.


Create a global/test instance flag.

Diez
Sep 25 '05 #2
Diez B. Roggisch wrote:
paul kölle wrote:
hi all,

I noticed that setUp() and tearDown() is run before and after *earch*
test* method in my TestCase subclasses. I'd like to run them *once* for
each TestCase subclass. How do I do that.

Create a global/test instance flag.


I'm not sure if I understood what you mean, I tried:

setup = 'down'

class BaseTest(unittest.TestCase):
def setUp(self):
global setup
if setup == 'up':
print 'Not running setUp() again...'
return
...
all setup work goes here.
...
setup = 'up'
This didn't work, (tried to reset the flag in the last test* method to
'down', no dice)
and:

class BaseTest(unittest.TestCase):
def __init__(self, ...):
unittest.TestCase.__init__(self, ...)
self.setup = 'down'

def setUp(self):
if self.setup == 'up':
return
dowork
self.setup = 'up'

Failed also, I'm not sure why, __init__ was called way too often and
self.setup was always reset to 'down'. I finally gave up and created my
own method which I call in *every* test* method which is ugly, leads to
longer runtime and code duplication.
But at least it encouraged me to read the unittest docs more carefully.
Now I seem to understand that:

TestSuite.addTest(TestCaseSubclass('testSomething' ))
TestSuite.addTest(TestCaseSubclass('testSomethingO ther'))

will create two instances of TestCaseSubclass, so there is no way that
'testSomethingOther' will ever see what 'testSomething' might have
created if all work is done with instance data right? Initially I
thought it goes like: "run setUp(), run all test* methods, run
tearDown()" and that is what the unittest docs call a "fixture"

<cite python 2.3 docs for unittest>
A test fixture represents the preparation needed to perform one or more
tests, and any associate cleanup actions.
</cite>

but further down:
<cite python 2.3 docs for unittest>
Each instance of the TestCase will only be used to run a single test
method, so a new fixture is created for each test.
</cite>

It seems to me my case is not that exotic, I thought it would be quite
natural to write the boilerplate stuff in setUp() and build on that to
step through the applications state with test* methods each building on
top of each other. Is that the wrong approach? Are there other
frameworks supporting such a style?

thanks
Paul

Sep 25 '05 #3
"paul kölle" <pa**@subsignal.org> wrote:

[snipped]

It seems to me my case is not that exotic, I thought it would be quite
natural to write the boilerplate stuff in setUp() and build on that to
step through the applications state with test* methods each building on
top of each other. Is that the wrong approach? Are there other
frameworks supporting such a style?


Yes, py.test: http://codespeak.net/py/current/doc/test.html.

George
Sep 26 '05 #4
[George Sakkis]
Yes, py.test: http://codespeak.net/py/current/doc/test.html.


The whole http://codespeak.net site contains many interesting projects,
which are all worth a good look!

However, there is a generic ``LICENSE`` file claiming copyrights on all
files, without explaining what the copyright conditions are. This file
also delegates copyright issues to individual files, which are usually
silent on the matter. Could this whole issue be clarified? Or did I
miss something I should not have?

--
François Pinard http://pinard.progiciels-bpi.ca
Sep 26 '05 #5
paul kölle wrote:
hi all,

I noticed that setUp() and tearDown() is run before and after *earch*
test* method in my TestCase subclasses. I'd like to run them *once* for
each TestCase subclass. How do I do that.


One way to do this is to make a TestSuite subclass that includes your startup and shutdown code.

For example I have some tests that rely on a webserver being started. I have a TestSuite that starts the server, runs the tests and stops the server. This way the server is only started once per test module. Here is the TestSuite class:

class CbServerTestSuite(unittest.TestSuite):
''' A test suite that starts an instance of CbServer for the suite '''
def __init__(self, testCaseClass):
unittest.TestSuite.__init__(self)
self.addTest(unittest.defaultTestLoader.loadTestsF romTestCase(testCaseClass))

def __call__(self, result):
CbServer.start()
unittest.TestSuite.__call__(self, result)
CbServer.stop()
I use it like this:

class MyTest(unittest.TestCase):
def testWhatever(self):
pass

def suite():
return CbServerTestSuite(MyTest)

if __name__=='__main__':
unittest.TextTestRunner().run(suite())
This runs under Jython (Python 2.1); in more recent Python I think you can override TestSuite.run() instead of __call__().

Kent
Sep 30 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Will Stuyvesant | last post: by
2 posts views Thread by JAWS | last post: by
reply views Thread by Remy Blank | last post: by
3 posts views Thread by Qiangning Hong | last post: by
reply views Thread by Chris Fonnesbeck | last post: by
2 posts views Thread by Collin Winter | last post: by
1 post views Thread by winston.yang | last post: by
reply views Thread by Nikolaus Rath | last post: by
1 post views Thread by Jean-Paul Calderone | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by Vinnie | last post: by
1 post views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.