[TIP] setUp and tearDown behavior

[holger krekel]

On Tue, Jan 19, 2010 at 14:23 -0500, Alfredo Deza wrote:
> On Tue, Jan 19, 2010 at 9:55 AM, holger krekel <holger at merlinux.eu> wrote:
> > The others gave various answers related to unittest and its extensions -
> > i'd like to add another way using py.test "funcargs".  The main advantage
> > is that you can completely decouple test fixture and actual test code,
> > allowing
> > for more flexibility and ease of doing functional/system testing.
> >
> > Would that be specific to py.test ? I am trying to build agnostic tests
> that can be run with anything
> and understood in the original way it was written.

What i described as an example is specific to py.test. 

If your goal is "agnostic" tests you might be cutting yourself
off from a lot of good resources though - be it py.test, nosetests,
testresources, subunit or other possibilities.  

cheers,
holger
 
> > Example: you write one or multiple test functions that look like this
> > (also can be put on a class of course):
> >
> >    def test_installer(setupdir):
> >        # do your tests, setupdir is your fixture state
> >
> > This is a test function that runs and works with a "setupdir" function
> > argument.
> > You define a function argument factory which is invoked to provide
> > an instance of it:
> >
> >    def pytest_funcarg__setupdir(request):
> >        return request.cached_setup(scope="session",
> >            setup=lambda: MySetupDir(),
> >            teardown=lambda mysetupdir: mysetupdir.finish()
> >        )
> >
> > The specified 'setup' and 'teardown' will be called exactly once per
> > session.  If you don't run a test that needs the funcarg the factory
> > function will not be called at all.  In any case, your test functions
> > can stay completely ignorant from how fixtures are managed.
> >
> > You can change scoping by modifying the factory function - e.g.
> > add a command line option that forces "function" scoping which usually
> > avoids "cascading failures" and provides better test isolation at the
> > expensve
> > of longer test run durations.  Useful for a nightly Continous Integration
> > configuration.
> >
> > Lastly, the 'request' object is a handle to the particular test
> > function - it provides access to the test function object, its module,
> > class object etc. and you can thus easily mark a test to receive a
> > specially parametrized "setupdir" ...  see http://tinyurl.com/yfw82l5
> > for details.
> >
> > cheers,
> > holger
> >
> 
> 
> 
> -- 
> Alfredo Deza

--