[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9231: Use of TAP in Automake's own testsuite: avoid NIH
From: |
Stefano Lattarini |
Subject: |
bug#9231: Use of TAP in Automake's own testsuite: avoid NIH |
Date: |
Wed, 3 Aug 2011 22:14:05 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#9231: Use of TAP in Automake's own testsuite: avoid NIH,
Stefano Lattarini <=