TBC: Testing By Convention

[ bsd3, library, program, testing ] [ Propose Tags ]

TBC is a harness for running tests, relying on other libraries such as QuickCheck and HUnit to do the actual testing. If the tests follow conventions, TBC lets you skip a lot of boilerplate.


[Skip to Readme]

Modules

[Last Documentation]

  • Test
    • Test.TBC

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.0.1, 0.0.2, 0.0.3
Dependencies base (>=4 && <5), Cabal, directory, filepath, process, unix [details]
License BSD-3-Clause
Copyright Peter Gammie, Mark Wotton
Author Peter Gammie, Mark Wotton
Maintainer peteg42@gmail.com
Category Testing
Source repo head: git clone git://github.com/peteg/TBC.git
Uploaded by PeterGammie at 2009-07-27T01:06:33Z
Distributions
Reverse Dependencies 1 direct, 0 indirect [details]
Executables tbc
Downloads 2818 total (12 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs not available [build log]
All reported builds failed as of 2016-12-31 [all 9 reports]

Readme for TBC-0.0.1

[back to package description]
= TBC: Test by Convention =

TBC provides two features:

- It attempts to compile and run all tests, even if some do not
  compile or run.
- Aspiring to the write-it-once principle, tests following
  conventions require a lot less boilerplate.

Inspired by test-based development, our aim is not to displace
existing tools such as QuickCheck and HUnit but to make a project's
tests more useful when things are in an inconsistent state. TBC is
also useful for supporting 'what-if' experiments, aiding program
comprehension.

TBC is presently alpha. It has proven useful to the authors but is
embryonic in many ways.

The directory 'Sample/' contains a sample project following TBC
conventions. We suggest running 'tbc' in that directory as a quick way
of understanding what it can do.

== Conventions ==

Tests live in $PROJECT/Tests. Test-specific hierarchical modules can
also exist there.

Within a test file, lines beginning with _ should _ when evaluated:

"exception_" / throw an exception.
"hunit_" / be HUnit tests: TBC applies "runTestTT . test" to them.
"ok_" / not throw an exception.
"prop_" / be QuickCheck tests: TBC applies "test" to them.
"test_" / be boolean tests (of type Bool or IO Bool or IO () with a
print statement or ...): TBC runs them and expects the final line of
output to be "True".

The tests themselves must ensure the test framework (QuickCheck, etc.)
is in scope, i.e. be executable as they are in GHCi.

The 'tbc' executable will search upwards for a '.cabal' file and
assumes the 'dist/' directory is in the same place.

== Invocation ==

There are two ways to use TBC:

- as a Cabal 'test' hook. This is not recommended as packages that do
  this cannot be uploaded to hackage. Perhaps changes in Cabal will
  make this more useful.

- invoking the 'tbc' executable.

The 'tbc' executable will search upwards in the directory hierarchy
for a .cabal file, and then go looking for tests in the current
directory and its children.

Presently it is best to run 'tbc' in the directory containing the
tests (or a subdirectory of it).

== Gotchas ==

Say:

tbc -v

for a verbose session.

It seems that the parts of Cabal that TBC depends on change
frequently. TBC has only been tested with the latest Cabal (>= 1.7)
from the darcs repository. It is probably not difficult to make it
work with earlier Cabals.

Conventions must retain the full name of the test, otherwise we run
into some nasty lexical issues, e.g. to avoid:

hunit_prop_blah =tName equals= prop_blah

We only support GHCi on *NIX presently.