[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.]
- Re: [lmi] Please review commit a929271, Greg Chicares, 2018/02/01
- Re: [lmi] Please review commit a929271, Vadim Zeitlin, 2018/02/01
- Re: [lmi] Please review commit a929271, Greg Chicares, 2018/02/02
- Re: [lmi] Please review commit a929271,
Greg Chicares <=
- Re: [lmi] Please review commit a929271, Vadim Zeitlin, 2018/02/07
- [lmi] Testable alternative to compressed PDFs [Was: Please review commit a929271], Greg Chicares, 2018/02/10
- Re: [lmi] Testable alternative to compressed PDFs, Vadim Zeitlin, 2018/02/10
- Re: [lmi] Testable alternative to compressed PDFs, Greg Chicares, 2018/02/10
- Re: [lmi] Testable alternative to compressed PDFs, Vadim Zeitlin, 2018/02/10
- Re: [lmi] Testable alternative to compressed PDFs, Greg Chicares, 2018/02/12