MyNixOS website logo
Description

Run TLT tests from Tasty.

TLT is a quick-and-dirty unit test system without test specifications, motivated by easy examination of intermediate results of computations in monad transformers. See the GitHub repository https://github.com/jphmrst/TLT/ for documentation, or the Haddock page for additional examples.

TLT

TLT is a Haskell test framework oriented towards stacked monad transformers. TLT has no explicit test specifications. Tests are run where declared, with results accumulated and reported at the end. Tests can live in an arbitrary monad transformer so long as the TLT transformer is part of the stack. Some control of the results display is available.

See also the TLT Haddock page for additional examples.

Overview

A TLT test is a command in the TLT monad transformer. There is no separation between the specification and execution of a test; TLT makes no record of an executable test itself, only of its result. So in the main instance for testing, the core IO monad should be wrapped in the TLT transformer, and in whatever other layers are also to be tested.

In TLT, all tests are associated with a string which names or otherwise describes the test. Each test is introduced with one of the ~:, ~::, or ~::- infix operators.

The simplest tests simply look for a True boolean value. These tests are introduced with ~:: or ~::-. The difference between the two is whether the boolean value is the result of a pure Bool expression, or whether it is returned as the result of a computation. In TLT, we distinguish between the two cases by including a trailing hyphen - to operators on pure expressions, and omitting the hyphen from operators on monadic arguments. So these two tests will both pass,

"2 is 2 as single Bool" ~::- 2 == 2
"2 is 2 a returned Bool" ~:: return $ 2 == 2

The ~: operator introduces a more general form of test. The right-hand side of ~: should be an Assertion formed with one of TLT's built-in assertion operators, or returned from a package's custom assertions. Assertions can give more detailed failure information then simple Bools.

Syntactically, most assertions are infix operators which start with a @ character. The value to the left of the operator is the expected value, and the symbol to the right is (or returns) the value under test. A hyphen or P suffixes assertion operators which operate on pure values; for operators without the trailing hyphen, the value under test should is expected to be returned as the result of a monadic computation (as with ~:: and ~::-).

TLT provides these assertion operators:

OperatorMeaning
expected @== monadicThe actual result must be equal to the given expected result.
expected @==- expr
unexpected @/= monadicThe actual result must differ from the given unexpected result.
unexpected @/=- expr
expected @< monadicThe actual result must be greater than the given lower bound.
expected @<- expr
expected @ monadicThe actual result must be less than the given upper bound.
expected @>- expr
expected @<= monadicThe actual result must be greater than or equal to the given lower bound.
expected @<=- expr
expected @>= monadicThe actual result must be less than or equal to the given upper bound.
expected @>=- expr
empty monadicThe actual result must be an empty Traversable structure.
emptyP expr
nonempty monadicThe actual result must be a nonempty Traversable structure.
nonemptyP expr
nothing monadicThe actual result must be Nothing (in a Maybe-typed value)
nothingP expr
assertFailed messageTrivial assertions, intended for the less interesting branches of conditional and selection expressions.
assertSuccess

Note that although the assertions are in pairs of one for testing a pure expression value, and one for testing the result returned from a monadic computation, in all of the builtin binary assertions the /expected/ value argument is always a pure value, not itself monadic.

The inGroup function allows related tests to be reported as a group. The function takes two arguments, a String name for the group, and the TLT computation housing its tests. Groups have impact only in terms of organizing the output you see in the final report of tests run.

Finally, it is straightforward to write new Assertions for project-specific test criteria: they are simply functions returning monadic values. There are several functions in the final section of this document which transform pure predicates into Assertions, or which transform one form of Assertion into another.

Examples

These examples are from the sample executables and test suite of the TLT package.

A simple example

The tests in this example are vacuous, but they show a simple setup with both passing and failing tests.

main :: IO ()
main = do
  tlt test

test :: Monad m =    TLT m ()
test = do
  "True passes" ~::- True
  "2 is 3 as single Bool" ~::- 2 == 3
  "2 is 2 as single Bool" ~::- 2 == 2
  inGroup "== assertions" $ do
    inGroup "pure" $ do
      "2 is 3 as pure assertion" ~: 2 @==- 3
      "2 is 2 as pure assertion" ~: 2 @==- 2
    inGroup "monadic" $ do
      "2 is 3 as result" ~: 2 @== return 3
      "2 is 2 as result" ~: 2 @== return 2
  inGroup "/= pure assertions" $ do
    "2 not 3" ~: 2 @/=- 3
    "2 not 2" ~: 2 @/=- 2
  "2 not 3 as result" ~: 2 @/= return 3
  "2 not 2 as result" ~: 2 @/= return 2

Running these tests should give:

Running tests:
- 2 is 3 as single Bool: FAIL Expected True but got False
- == assertions:
  - pure:
    - 2 is 3 as pure assertion: FAIL Expected 2 but got 3
  - monadic:
    - 2 is 3 as result: FAIL Expected 2 but got 3
- /= pure assertions:
  - 2 not 2: FAIL Expected other than 2 but got 2
- 2 not 2 as result: FAIL Expected other than 2 but got 2
Found 5 errors in 11 tests; exiting

Note that only failing tests appear. This can be configured in the test command: add a call at the beginning of test to reportAllTestResults to control this behavior:

test :: Monad m =    TLT m ()
test = do
  reportAllTestResults True
  "True passes" ~::- True
  ...

and the output will be

Running tests:
- True passes: Pass
- 2 is 3 as single Bool: FAIL Expected True but got False
- 2 is 2 as single Bool: Pass
- == assertions:
  - pure:
    - 2 is 3 as pure assertion: FAIL Expected 2 but got 3
    - 2 is 2 as pure assertion: Pass
  - monadic:
    - 2 is 3 as result: FAIL Expected 2 but got 3
    - 2 is 2 as result: Pass
- /= pure assertions:
  - 2 not 3: Pass
  - 2 not 2: FAIL Expected other than 2 but got 2
- 2 not 3 as result: Pass
- 2 not 2 as result: FAIL Expected other than 2 but got 2
Found 5 errors in 11 tests; exiting

Testing monad transformers

In the previous example TLT was the outermost (in fact only) monad transformer, but it can appear at any level of the test suite's application stack. Using TLT at other than the top level is easiest when all of the transformers which might wrap it are declared as instances of MonadTLT.

Consider an application which declares two monad transformers M1T and M2T. For simplicity here we take them to be just aliases for IdentityT:

newtype Monad m =    M1T m a = M1T { unwrap1 :: IdentityT m a }
runM1T :: Monad m =    M1T m a -    m a
runM1T = runIdentityT . unwrap1

newtype Monad m =    M2T m a = M2T { unwrap2 :: IdentityT m a }
runM2T :: Monad m =    M2T m a -    m a
runM2T = runIdentityT . unwrap2

And we elide the usual details of including each of them in Functor, Applicative, Monad and MonadTrans. We can declare instances of each in MonadTLT,

instance MonadTLT m n =    MonadTLT (M1T m) n where
  liftTLT = lift . liftTLT

and similarly for M2T. Note that this declaration does require FlexibleInstances (because n does not appear in the instance type), MultiParamTypeClasses (because we must mention both the top transformer m and the monadic type n directly wrapped by TLT within m), and UndecidableInstances (because n is not smaller in the recursive context of MonadTLT, which is not actually a problem because in the definition of MonadTLT, n is functionally dependent on m, which /is/ smaller in the recursive context) in the module where the MonadTLT instance is declared.

Now it is convenient to test both transformers:

ttest = do
  runM1T $ inGroup "M1T tests" $ m1tests
  runM2T $ inGroup "M2T tests" $ m2tests

m1tests = M1T $ do
  "3 is 3 as pure assertion" ~: 3 @==- 3
  "4 is 4 as pure assertion" ~: 4 @==- 4

m2tests = M2T $ do
  "5 is 5 as pure assertion" ~: 5 @==- 5
  "6 is 6 as pure assertion" ~: 6 @==- 6

It is not necessary, for example, to harvest test declarations from the executions of the MnTs for assembly into an overall test declaration.

Metadata

Version

0.0.0.0

Platforms (77)

    Darwin
    FreeBSD
    Genode
    GHCJS
    Linux
    MMIXware
    NetBSD
    none
    OpenBSD
    Redox
    Solaris
    WASI
    Windows
Show all
  • aarch64-darwin
  • aarch64-freebsd
  • aarch64-genode
  • aarch64-linux
  • aarch64-netbsd
  • aarch64-none
  • aarch64-windows
  • aarch64_be-none
  • arm-none
  • armv5tel-linux
  • armv6l-linux
  • armv6l-netbsd
  • armv6l-none
  • armv7a-darwin
  • armv7a-linux
  • armv7a-netbsd
  • armv7l-linux
  • armv7l-netbsd
  • avr-none
  • i686-cygwin
  • i686-darwin
  • i686-freebsd
  • i686-genode
  • i686-linux
  • i686-netbsd
  • i686-none
  • i686-openbsd
  • i686-windows
  • javascript-ghcjs
  • loongarch64-linux
  • m68k-linux
  • m68k-netbsd
  • m68k-none
  • microblaze-linux
  • microblaze-none
  • microblazeel-linux
  • microblazeel-none
  • mips-linux
  • mips-none
  • mips64-linux
  • mips64-none
  • mips64el-linux
  • mipsel-linux
  • mipsel-netbsd
  • mmix-mmixware
  • msp430-none
  • or1k-none
  • powerpc-netbsd
  • powerpc-none
  • powerpc64-linux
  • powerpc64le-linux
  • powerpcle-none
  • riscv32-linux
  • riscv32-netbsd
  • riscv32-none
  • riscv64-linux
  • riscv64-netbsd
  • riscv64-none
  • rx-none
  • s390-linux
  • s390-none
  • s390x-linux
  • s390x-none
  • vc4-none
  • wasm32-wasi
  • wasm64-wasi
  • x86_64-cygwin
  • x86_64-darwin
  • x86_64-freebsd
  • x86_64-genode
  • x86_64-linux
  • x86_64-netbsd
  • x86_64-none
  • x86_64-openbsd
  • x86_64-redox
  • x86_64-solaris
  • x86_64-windows