On 27.07.2013 19:06, John Ralls wrote:

On Jul 27, 2013, at 8:38 AM, Vassilii Khachaturov <vassilii@tarunz.org> wrote:

A short status update on this thread:

1) There is a new wiki page, "Testing Gramps", which is currently a stub, indexing all my current knowledge about testing in Gramps.
Call for action: please review the page, and add anything relevant that you know, even if in outline form.

2) The reports test runner script, runtest.sh, has been fixed and found 5 bugs, tagged with 'found-by-runtest.sh'. See the "attached issues" link from the tag page http://www.gramps-project.org/bugs/tag_view_page.php?tag_id=77

Two of the bugs have already been fixed by yours truly, and I have plans on fixing the remaining 3, but wait for various feedback there.

So this script does help gramps quality, and I strongly suggest everybody who performs changes in report-producing code, to play with it.

See more off the wiki page mentioned above.

3) RunAllTests.py, the unit test runner for unit test code located in test/ subdir, has also been fixed. 3 bugs I have fixed during that work relate to broken/outdated test code. One remaining bug, 6940, requires more work, and I'm waiting for input from Benny when he's back from the vacation, to understand what's going on there. Until it is fixed, this test runner script will show 1 failed test.

So if you feel like adding testing code to something you are developing/fixing now, you already can do it and run it using the "RunAllTests.py" runner.

4) Next time I've got some free cycles to work on this, I plan to revive the in-tree unit tests (e.g., the date_test.py, failing of which was mentioned earlier in this thread).

I believe that by getting the test toolset back in shape we'll be able to make gramps more stable.

Awesome! Thanks for taking this on -- it's something I've wanted fixed but never found time to work on.

Thank you very much for the kind words!

Can the "in-tree" tests reasonably be made to work from RunAllTests? Might RunAllTests be integrated into
setup.py, so that one can say `python setup.py test` (or check) instead of explicitly running a separate program?

Great idea, I think that running all the unit tests from a single toplevel place is the way to go.