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: Wed, 7 Feb 2018 22:37:28 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

[There's one idea here that seems compelling, and I'm writing this
to suggest that we pursue it...while still holding the other, less
compelling, idea in abeyance.]

On 2018-02-02 15:06, Greg Chicares wrote:
> 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.

That's the idea that seems compelling.

>> 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.

That's the one that doesn't seem compelling.

[Reading this again, it seems to me that the last two words could
be taken as applying to everything that preceded them, and I want
to clarify that that is not the intention.]



reply via email to

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