> I've just read the specification and I don't think it buys us much. I wasn't suggesting TAP so much as recommending Perl's prove(1) for handling unit tests. It eliminates portability headaches and issues with Bashisms <http://mywiki.wooledge.org/Bashism>, and is pretty time-tested as far as assurance goes.
> Yeah, but would it tighten the versioning of our Perl dependency? I doubt it. Provided you stick with Perl 5.14 syntax (2011—present), there shouldn't be any portability or versioning issues. > 2. The ease of writing new tests, which should ideally be done by the > person implementing the feature or bug fix. Shell script knowledge is > almost as ubiquitous as POSIX shells themselves. You make a good point. I hadn't considered that. Although I'm wondering how many folks comfortable with shell-scripting would have problems writing a few basic Perl scripts... ;-) (Then again, I'm comfortable programming in both languages, so perhaps I'm biased too…) > > And who knows--maybe a gditroff page counting utility is something we > > should write and add to the distribution. > > $ printf '%s\n.bp\n' `seq 42` | groff -Z | grep -c ^p > 43 Ralph beat me to it, so I'll jokingly recommend adding my awesomely-useless <https://github.com/Alhadis/Roff.js/blob/9f4c65cd8efe081bd3888e19817b25889f9b2bb5/bin/cat2dit> 1977 C/A/T-to-ditroff driver for distribution with Groff as well: ;-) $ file ./v7-troff.cat test/fixtures/cat/v7-troff.cat: very old (C/A/T) troff output data $ cat2dit -Tps ./v7-troff.cat x T ps x res 72000 1 1 x init p1 x font 1 TR x font 2 TI x font 3 TB x font 4 S f1 s10000 v12024 h7181 … On Tue, 31 Dec 2019 at 19:22, Ralph Corderoy <ra...@inputplus.co.uk> wrote: > Hi John, > > > Wouldn't having a TAP <https://testanything.org/> harness be > > preferable to hand-spun shell-scripts? > > I've just read the specification and I don't think it buys us much. > Something still needs to set up the test, run it, echo `ok' for TAP, and > clean up, and something above that needs to run a bunch of tests. TAP > just seems to summarise ok lines and spot they may have been too few? > > > I was rather shocked to learn such a widely-used program as Groff had > > such minimal test coverage. Testing the output of binary formats is > > understandably difficult, but I think most of those pains can be > > alleviated by testing against Groff's intermediate output format > > first, and then having unit tests assert proper transformation after. > > And testing by cmp(1)-ing two canonical PPMs, each containing a page > rendered by Ghostscript, one golden, the other new, would also catch a > lot of regressions for little work, leaving what exactly had caused the > pixels to change as a task for `git bisect'. > > It would have caught things like > https://bugs.launchpad.net/ubuntu/+source/groff/+bug/42764 > > -- > Cheers, Ralph. > >
