Hi Ralph, On Sun, Jan 05 2020 at 06:20:10 PM, Ralph Corderoy <ra...@inputplus.co.uk> 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
