GNU bug report logs - #9231
Use of TAP in Automake's own testsuite: avoid NIH

Previous Next

To reply to this bug, email your comments to 9231 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Use of TAP in Automake's own testsuite: avoid NIH
Date: Wed, 3 Aug 2011 22:14:05 +0200

Severity: wishlist

OK, I gotta admit that the shell-oriented "TAP library" I've introduced in
the 'test-protocols' branch[*] is probably one of worst example of the NIH
syndrome *ever*.  It's mostly OK for the simple uses I've put it to for
the moment, but I can see that, if mismanaged, it could either remain
brittle and inadequate (and force us to write more convoluted, indirected
tests), or, on the other hand, become another complex package-in-a-package
maintainance nightmare.

 [*] See commit `v1.11-920-gc349db0' "testsuite: scaffolding to allow use of
     TAP in our own tests":
  <https://lists.gnu.org/archive/html/automake-patches/2011-08/msg00015.html>

We should fix this creeping NIH-ness in the future, taking inspiration from
pre-existing, real-world TAP generators implementated in the shell; among
them are, e.g.:

  1. The `t/test-lib.sh' library in the Git testsuite:
     <http://git.kernel.org/?p=git/git.git;a=blob;f=t/test-lib.sh>

  2. The `tap/libtap.sh' from the "C TAP Harness" package:
     <http://git.eyrie.org/?p=devel/c-tap-harness.git;a=blob;f=tap/libtap.sh>

Note that those implementations will still require some editing and reshaping
in order to fit in the current Automake testing framework.

Thanks,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.