[TIP] Hint on TestClass

[holger krekel]

Hello Thijs,

On Sat, Jul 14, 2012 at 10:22 +0200, Thijs Engels wrote:
> Holger,
> 
> Thank you very much for your response, I have been able to make progress
> on this now.
> 
> This actually brings me to a question on the same topic. What is the
> meaning of classes in py.test (over just functions)? It is merely for me
> as the user to have an overview? Asking this question with
> parametrization in mind. I thought that a class would be considered a
> suite with a collection of tests which should be run as a group, short
> example the file with tests:
> 
> class TestSession:
>     def test_id(self, session):
>         assert isinstance(session.id, int)
>         assert session.id > 0
> 
>     def test_date(self, session):
>         assert isinstance(session.delivery_date, date)
>         assert session.delivery_date > date(2010, 12, 31)
> 
> The session parameter is parametrized via the indirect option combined
> with the factory function as indicated in your earlier response
> (currently limited to three sessions).
> 
> Running this results in this (verbose) output:
> 
> test_universe.py:4: TestSession.test_id[1] PASSED
> test_universe.py:4: TestSession.test_id[2] PASSED
> test_universe.py:4: TestSession.test_id[3] PASSED
> test_universe.py:8: TestSession.test_date[1] PASSED
> test_universe.py:8: TestSession.test_date[2] PASSED
> test_universe.py:8: TestSession.test_date[3] PASSED
> 
> As the session information is retrieved from a database I would prefer
> to first do all tests on session object 1, before starting on session 2,
> hence the output I would like is:
> 
> test_universe.py:4: TestSession.test_id[1] PASSED
> test_universe.py:8: TestSession.test_date[1] PASSED
> test_universe.py:4: TestSession.test_id[2] PASSED
> test_universe.py:8: TestSession.test_date[2] PASSED
> test_universe.py:4: TestSession.test_id[3] PASSED
> test_universe.py:8: TestSession.test_date[3] PASSED
> 
> As stated earlier I thought this could be done via a TestClass, which
> need the additional self parameter which shows up in the debug output
> for failed tests as well. Is there a way to construct (parametrized)
> test suites?

There is no config/command line option for this.
I just wrote a little example showing how you can do it, however:

    http://pytest.org/dev/example/parametrize.html#grouping-test-execution-by-parameter

best,
holger


> 
> Kind regards,
> 
> Thijs
> 
> On Thu, Jul 12, 2012, at 06:27, holger krekel wrote:
> > Hi Thijs,
> > 
> > On Wed, Jul 11, 2012 at 16:26 +0200, Thijs Engels wrote:
> > > Hello all,
> > > 
> > > I am currently running multiple tests (using py.test) on a series of
> > > objects which are relatively expensive to retrieve. My thinking was to
> > > group the tests on the same object into one class, potentially using the
> > > setup/teardown at class level to retrieve the object under test.
> > 
> > This is a classic use case for "funcargs".  See here for a basic example:
> > 
> > http://pytest.org/latest/example/parametrize.html#deferring-the-setup-of-parametrized-resources
> > 
> > In addition, you probably want to extend the setup of resources by
> > using the request.cached_setup() helper like so:
> > 
> >     def pytest_funcarg__db(request):
> >         if request.param == "d1":
> >             return request.cached_setup(setup=DB1, scope="session",
> >                                         extrakey=request.param)
> >         ...
> > 
> > This will make sure that your setup function (in this case the DB1 class)
> > will only be called once per session.  Other scopes are "class" or
> > "module".
> >     
> > > As mentioned there is a series of these objects, hence I would like to
> > > parametrize the class holding all the individual tests. Via the search
> > > on the py.test I actually landed on a page which seems to describe
> > > exactly what I am after:
> > > http://pytest.org/dev/example/resources_attic.html, although I could not
> > > complete figure out the given example with self.db.
> > 
> > Not sure how you could find "attic" documents but this is not a valid
> > suggestion these days. 
> > 
> > best,
> > holger
> > 
> > 
> > > 
> > > This is about what I hoping to archive:
> > >   Use parametrize to run the test in TestSession for a list of
> > >   session_ids.
> > > 
> > > TestSession:
> > >   def __init__(self, session_id):
> > >     self.session = expensive_database_query(session_id)
> > > 
> > >   def test_session_id():
> > >     assert session.id > 0
> > > 
> > >   def test_session_date():
> > >     assert session.date >= date(2012, 1, 1)
> > > 
> > >   def test_periods():
> > >     assert periods in range(1, 26)
> > > 
> > > Is the resource_attic link indeed describing what I am after?
> > > 
> > > Thijs
> > > 
> > > _______________________________________________
> > > testing-in-python mailing list
> > > testing-in-python at lists.idyll.org
> > > http://lists.idyll.org/listinfo/testing-in-python
> > > 
>