lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Please review commit a929271


From: Vadim Zeitlin
Subject: Re: [lmi] Please review commit a929271
Date: Thu, 1 Feb 2018 23:35:18 +0100

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.

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?

 Thanks,
VZ


reply via email to

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