Hi Oliver, I really appreciate the Hudson setup. Count me in for work that gets more green lights.
I like Nose. I've been using it whenever possible for the last few years. Shapely's test runner predates my experience with Nose, and I haven't switched over because of the doctest suites legacy. Like you said, the manual makes the doctest code examples redundant. I'll gladly accept converted tests that maintain or improve existing coverage: $ coverage -r shapely/*.py shapely/geometry/*.py Name Stmts Exec Cover ------------------------------------------------------ shapely/__init__ 0 0 100% shapely/coords 113 108 95% shapely/ctypes_declarations 176 176 100% shapely/geometry/__init__ 9 9 100% shapely/geometry/base 254 219 86% shapely/geometry/collection 17 10 58% shapely/geometry/geo 47 29 61% shapely/geometry/linestring 121 88 72% shapely/geometry/multilinestring 64 48 75% shapely/geometry/multipoint 96 85 88% shapely/geometry/multipolygon 81 72 88% shapely/geometry/point 121 103 85% shapely/geometry/polygon 244 205 84% shapely/geometry/proxy 34 33 97% shapely/geos 244 166 68% shapely/impl 38 38 100% shapely/iterops 32 27 84% shapely/linref 17 17 100% shapely/ops 55 53 96% shapely/predicates 16 13 81% shapely/prepared 24 18 75% shapely/topology 41 38 92% shapely/validation 3 3 100% shapely/wkb 21 16 76% shapely/wkt 17 12 70% ------------------------------------------------------ TOTAL 1885 1586 84% Cheers, On Wed, Sep 29, 2010 at 12:32 PM, Oliver Tonnhofer <[email protected]> wrote: > Hi everyone, > > I have setup a continuous integration server (hudson) for Shapely: > http://dev.mapproxy.org:8080/job/shapely/ > It runs the Shapely tests with Python 2.5, 2.6 and 2.7 and each with GEOS > 3.1.0 (Ubuntu default), 3.1.1 and 3.2.2 (both set with LD_LIBRARY_PATH). It > works pretty well except for the doctests with Python 2.7. > > I like doctest, they are a good way to document an API and it is easy to > produce 'testable' documentation. But they have limitations. First, they only > check against strings which does not work reliable when the formatting > changes. Best example here are floating point numbers in different Python > versions. Second, they are not flexible enough. I had to rewrite > linear-referencing.txt to a unittest.TestCase, because it is not possible to > skip a doctest (the tested methods in that file are only available since 3.2). > > I would volunteer to convert the other doctests to unittest.TestCases, if > nobody objects. That way all tests should also run on 2.7. The doctests are > nice to read, but since Sean provided a great manual for Shapely, it wouldn't > be a great loss. > > Another point I'd love to change is the test-runner. The Python unittest > framework requires manual building of the test suites and this is error > prone. I use nosetests[0] for some projects and it is really great. It has > auto-discovery of all tests (even unittest.TestCase), test generators[1] and > a large list of plugins (like code coverage or XML output for hudson). What > do you think? Are there any reasons to keep unittest? Has anyone good/bad > experience with nosetests? > > [0] http://somethingaboutorange.com/mrl/projects/nose/0.11.2/testing.html > [1] > http://somethingaboutorange.com/mrl/projects/nose/0.11.2/writing_tests.html#test-generators > > > Regards, > Oliver > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community > _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
