Re: [lmi] Please review commit a929271

[Greg Chicares]

On 2018-02-01 22:35, Vadim Zeitlin wrote:
> On Thu, 1 Feb 2018 16:16:50 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-01-31 23:34, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  I also wonder if it could be worth adding a script/commit hook/make 
> target
> GC> > checking that all the variables present in .mst files are at least
> GC> > mentioned in the C++ code too. What do you think?
> GC> I think it would be better to make the automated GUI test create one
> GC> PDF illustration for each "ledger type". That's a more powerful test;
> 
>  What exactly would it test? Just that the PDF creation succeeded? If you
> remember, we discussed testing the generated PDFs before starting this
> project but I don't think we found any satisfactory solution for this.

Yes, I'm sure we didn't find a good solution, but maybe we should take
a fresh look now. Kim told me that some other vendor offers an option
to generate text files for regression testing, as an alternative to PDF
files for actual production. We don't know exactly how they do this,
but perhaps there's a way to make our new PDF code emit flat text as an
optional side effect. That would enable automated regression testing of
a PDF file's content only, not its physical layout; but it would still
be very useful.

There are probably free (as in software) tools that could extract the
text contents of a PDF file, but I tend to think it would be nicer to
generate text output ourselves.

> GC> Perhaps we should just add a 'pdf_test' path (akin to the existing
> GC> 'gui_test' path) to 'wx_test'. Then the person running the tests
> GC> could populate that directory with input files representing any
> GC> range of PDF capabilities that seems useful; the test would run
> GC>   Census | Print case to PDF [for '.cns' input]
> GC>   File | Print to PDF [for '.ill' input]
> GC> and, for other file types, just print a diagnostic. Does that seem
> GC> like a good idea?
> 
>  It definitely wouldn't hurt to run it even if the test does nothing more
> than generate the files, but I'm not really well-placed to know how useful
> would it be.
> 
>  Would you like me to implement such "pdf_test" target right now or should
> it wait until the new PDF implementation becomes the default (and the only)
> one?

Let's wait.