I agree about having different levels of granularity.

Two advantages of an OtmTestCase class with data init methods rather than a
module with data init functions:

1) The methods can set attributes on self, which the test methods can then
reference. With functions you'd have to set module-level variables to do
the same thing. I guess that's not horrible.

2) Test case classes can just inherit from OtmTestCase, rather than having
to import particular functions. But you could just import module, not
horrible either.

OK, so using a module would look like this:

```
import treemap.setup_db_for_tests as setup

class MyTests(TestCase):
    def test_favicon(self):
        setup.make_lots_of_stuff()
        do_something(setup.boundary1)
```

And using a class would look like this:

```
from treemap import OtmTestCase

class MyTests(OtmTestCase):
    def test_favicon(self):
        self.make_lots_of_stuff()
        do_something(self.boundary1)
```

While I prefer the latter, it's not enough better to lose first-class
functions. Bad, bad Python classes.

-Rick









On Mon, Aug 5, 2013 at 3:43 PM, Steve Lamb <notifications@github.com> wrote:

> In opentreemap/treemap/tests/urls.py:
>
> > @@ -0,0 +1,153 @@
> > +import os
> > +
> > +from django.contrib.gis.geos.collections import MultiPolygon
> > +from django.contrib.gis.geos.point import Point
> > +from django.contrib.gis.geos.polygon import Polygon
> > +from django.test import TestCase
> > +
> > +from treemap.models import User, Boundary, Plot
> > +from treemap.tests import (make_instance, make_god_role)
> > +from opentreemap.local_settings import STATIC_ROOT
> > +
> > +class UrlTestCase(TestCase):
> > +
> > +    def make_god_user(self):
>
> I agree that the tests are full of setup duplication, but I would prefer
> to a keep a module/function pattern over class/method pattern for this
> case. It's not clear to me what a class buys us in exchange for the
> flexibility of first class functions.
>
> I do think you are right that there is tons of duplication and that the
> utility functions have grown organically without much consideration for
> progressively increasing abstractions.
>
> I think it would be awesome if the author of a test case could reach
> deeper into the module for lower level functions until they reach their
> desired level of granularity. For example, there could be a make_god_roleand a
> make_god_user function, each satisfying the most common use case, with
> make_god_user being the preferred, high-level utility. When the test
> author needs to do something a little bit different, they can drill in with
> make_god_role.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/azavea/OTM2/pull/142/files#r5587937>
> .
>



-- 
Rick Mohr, Software Developer

Azavea |  340 N 12th St, Ste 402, Philadelphia, PA
rmohr@azavea.com  | T 215.701.7504  | F 215.925.2663
Web azavea.com <http://www.azavea.com/>  |  Blog
azavea.com/blogs<http://www.azavea.com/Blogs>
| Twitter @azavea <http://twitter.com/azavea>