Re: GNUism in groff tests, was: pic anomalies

[John Gardner]

> 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 <address@hidden> 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.
>
>