Friday, December 6, 2019

Today’s changes are about two things.

Optimizations around MissingAccount

I fixed two bugs that came when some common account was not configured: A bug in lino_xl.lib.sheets that caused a TypeError “int() argument must be a string, a bytes-like object or a number, not ‘MissingAccount’” when you tried to render lino_xl.lib.sheets.Report. And an AttributeError “‘MissingAccount’ object has no attribute ‘get_detail_action’” when tried to show the list of trade types.

The std fixture for lino_xl.lib.accounting now deliberately leaves one common account (the “Net loss” one, which isn’t used anywhere so far) without a database object in order to reproduce this situation. I added test cases to cover it.

Testing the content of a detail window

After this side step I can finally configure the fields of the VAT declaration…

… but the main challenge with this task is that the mere testing of the results (“Is the number in field XYZ correct?”) is a lot of work because it requires diving into the stuff and the language of VAT offices. I want to do that work only once if possible. IOW : no manual testing. Everything must be tested in the specs. A good example of where you want test-driven development.

And Lino does not yet have a way to say in a doctest:

>>> obj = eevat.VatDeclaration.objets.get(id=3)
>>> rt.show(obj)
(and the expected output would be a textual representation of a detail window of
that database object)

So I opened #3395. At first I thought about doing it with Selenium, but then I simply extended lino.utils.py2rst() to also support rendering a database object. I added a test case to the specs page for eevat : Estonian VAT declarations.

Voilà, testing is set up. I can start doing that dull work of configuring those damn VAT fields.