lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Please review commit a929271


From: Greg Chicares
Subject: Re: [lmi] Please review commit a929271
Date: Thu, 1 Feb 2018 16:16:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 2018-01-31 23:34, Vadim Zeitlin wrote:
[...]
>  I also wonder if it could be worth adding a script/commit hook/make target
> checking that all the variables present in .mst files are at least
> mentioned in the C++ code too. What do you think?
I think it would be better to make the automated GUI test create one
PDF illustration for each "ledger type". That's a more powerful test;
and, because it would be run only on demand, it wouldn't make the git
hooks slower.

This might seem to violate the principle of separation of concerns,
by conflating the GUI and PDF notions. Such an assertion could be
rebutted by pointing out that those notions are architecturally bound
together--that the 'wx_test' binary properly tests all wx-dependent
features. [It might be sidestepped by adding a makefile target that
performs such tests by invoking 'lmi_wx_shared' with command-line
arguments calling for PDF generation from one input file of each
ledger type; but it appears:
  $wine ./lmi_wx_shared --help
that this binary lacks the required options that 'lmi_cli_shared'
provides, so this doesn't seem to be the easiest path.]

Perhaps we should just add a 'pdf_test' path (akin to the existing
'gui_test' path) to 'wx_test'. Then the person running the tests
could populate that directory with input files representing any
range of PDF capabilities that seems useful; the test would run
  Census | Print case to PDF [for '.cns' input]
  File | Print to PDF [for '.ill' input]
and, for other file types, just print a diagnostic. Does that seem
like a good idea?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]