Re: Testing groff. Was: GNUism in groff tests

[Bertrand Garrigues]

Hi Ralph,

On Sun, Jan 05 2020 at 06:20:10 PM, Ralph Corderoy <address@hidden> wrote:
>> Werner wrote:
>> > I think the proper way for testing groff would be to make it run
>> > with a fuzzer,
>>
>> Yes, that would no doubt be useful.
> ...
>> is kind of orthogonal to developing a test suite, though.
> ...
>> A test suite, on the other hand, is most useful for making sure no
>> regressions creep into the functionality,
>
> I think that's groff's pressing need: stopping regressions.  Given what
> I imagine is the part-time nature of contributions, to a large code
> base, that implements a complex system of parts, e.g. the troff
> language, I suspect a fix to more delicate bug may be quite high risk of
> introducing a regression, and often this will be only apparent in the
> PostScript, PDF, or pixels on the page being different; no warnings,
> errors, or dumped core.

When I've started to study the groff code with the ultimate goal to
implement the Knuth-Plass algorithm (I hope I can resume this work this
year) my intention was to write unit tests at the C++ level (using
cppunit framework, it's integrated it in the 'format-knuth-plass'
branch).  The difficulty is that the 3 main files of 'troff' (input.cpp,
env.cpp, node.cpp) are quite large and tighly coupled, which makes it
difficult to test a single class.

Of course this approach will not catch any regression in macro packages
and is orthogonal to a suite of tests that would check the ps or pdf
output.

Regards,

Bertrand