20130415 (Monday, 15 April 2013)

Discovered several subtle problems especially in the welfare test suite.

Moved the test_them_all method from djangosite.utils.test.TestCase to a separate class djangosite.utils.test.AutoTestCase and converted all existing tests to not use it.

demo databases

The concept of the “demo database” of a project is indeed important for the test suite.

The demo database is a Django “project” with a persistent half-temporary database used for different purposes:

  • It is the active DJANGO_SETTINGS_MODULE while generating docs and/or userdocs using Sphinx.

  • Certain non-destructive tests may use it

“persistent” means that it is not populated automatically for each test run. When debugging a given test case it would be waste of time to populate a volatile memory database for each run.

“half-temporary” means that it can be re-generated easily using a simple command (probably fab initdb, which simply runs initdb_demo on this database). The developer decides whether it is necessary to re-create it.

The current implementation (env.django_databases in fabfile.py, now renamed to env.demo_databases), has the drawback of not being accessible by the project test suite. (I am not going to load the fabfile.py just to get the name of the demo database, am I?)

Because there’s is no easy solution for this problem, we currently need to explicitly repeat the name of the demo database in tests/__init__.py

Printing a Budget

The “Printing a Budget” section of tested/debts.rst was the guinea pig for the demo database. It did something like this:

>>> pprint(ses.run(obj.do_clear_cache))
{'message': u'Budget Nr. 3 f\xfcr Altenberg-Charlier printable cache has been cleared.',
 'refresh': True,
 'success': True}
>>> pprint(ses.run(obj.do_print)) 
{'message': u'Dokument Budget Nr. 3 f\xfcr Altenberg-Charlier wurde generiert.',
 'open_url': u'/media/userdocs/appyodt/debts.Budget-3.odt',
 'refresh': True,
 'success': True}

But even with the demo database reimplemented this still posed problems because the do_clear_cache action returns different messages depending on whether the document had been previously generated and/or user-modified.

To avoid these complications, I added a method clear_cache which is called by the do_clear_cache action and which can be called directly from code:

>>> obj.clear_cache()
>>> pprint(ses.run(obj.do_print)) 
{'message': u'Dokument Budget Nr. 3 f\xfcr Altenberg-Charlier wurde generiert.',
 'open_url': u'/media/userdocs/appyodt/debts.Budget-3.odt',
 'refresh': True,
 'success': True}

Detecting exceptions during appy_pod render

Worked on https://bugs.launchpad.net/appy/+bug/1169217

Most painful was the fact that appy has no setup.py and thus cannot be installed into a virtual environment using “pip install -e”.

I tried to use it directly from the development trunk by adding it manually to the PYTHONPATH. That worked seemingly… but when i started my own setup.py test there was some automatism causing another appy egg to be automatically downloaded and used.

So I finally reinstalled a released appy 0.8.3 and manually patched the egg.

Since the half solution works for me, I’m now finally (h)appy: I could reproduce a bug during printout of a debts.Budget with a single command (and which is new, in a few seconds):

$ python setup.py test -s tests.DocsTests.test_debts

The bug itself took then only a few minutes to find and eliminate. It was in lino.core.tables.TableRequest.get_field_info().