how exactly to do unit testing in scheme...

Christopher Lam christopher.lck at gmail.com
Sun Jan 28 03:42:21 EST 2018


Thank you Phil, with help from IRC I'll be separating the renderer into
multiple testable steps.

Options to accountlist, to splits, to filtered splits, and finally to
table.

Each one uses different parts of options.

On 26 Jan 2018 1:55 AM, "Phil Longstaff" <phil.longstaff at gmail.com> wrote:

> Usually, unit testing controller code is done by writing mocks for the
> code that is called. In this case, this would be the options.scm controller
> and the renderer. The mock code would test that the expected arguments are
> passed, and would return a canned response. This both checks the logic of
> the controller but also allows error and other paths to be tested.
>
> On Wed, Jan 24, 2018 at 11:03 AM, Christopher Lam <
> christopher.lck at gmail.com> wrote:
>
>> Dear Devel
>>
>> To rgmerk: Welcome back, and it was a nice to meet irl!
>>
>> While simplifying transaction.scm and thinking of unit testing, I now
>> have a conundrum worthy of an expert view.
>>
>> The reports require 2 main functions – the options generator and the
>> renderer; the options generator generates a options.scm controller object,
>> and the renderer takes options and outputs html.
>>
>> I understand unit testing to handle testing of ‘leaf’ functions e.g.
>> (split->date), rather than the controller code (e.g. renderer takes options
>> and outputs html) – but to me this is rather silly because split->date only
>> tests xaccTransGetDate and xaccSplitGetParent, whereas the controller tests
>> actual functionality.
>>
>> With regards to unit testing I can see several issues
>>
>> 1) The refactored report has inlined most single-use functions into
>> lambda expressions – I figured that directly stating (xaccTransGetDate
>> (xaccSplitGetParent split)) is much more descriptive to a programmer than
>> to create a testable leaf function (split->date split). I can see the
>> benefits of both – leave as lambda expressions which will can be
>> understandable by anyone who is familiar with the API, or break them out
>> into 100s of single use functions which can be tested, but introduces a
>> whole layer of cognitive load to anyone hacking code – (what does
>> split->date actually do? Where is its definition). Also, breaking the
>> lambda functions into testable functions means the implementation is frozen
>> and the next hacker will have lesser scope to rework/optimise the report.
>>
>> 2) The refactored report is now flexible enough to accommodate derived
>> reports with a different multicolumn data function – eg
>> income-gst-statement.scm has been reworked into a transaction.scm
>> derivative which passes its own calculated-cells to report on GST sales and
>> purchases. This is not yet committed.
>>
>> 3) I think the most useful testing approach for a complex transaction.scm
>> will be to test functions of various combinations of options values, and
>> test the resulting html for satisfactory output. There are now dozens of
>> bools and multichoices that can be triggered, each effecting html in
>> various ways. How best to test?
>>
>> 4) My view would be the unit test would check that:
>> a. the TR actually exists
>> b. it can display empty-report
>> c. it can understand passing of custom-calculated-cells
>> d. each of the options can be toggled, and the resulting html
>> displays/hides cells/detail as expected
>> e. and sorting options generate sorted rows
>>
>> Comments welcome, I had no formal training ☹
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
>


More information about the gnucash-devel mailing list