Test.HUnit.Base

Basic definitions for the HUnit library.

This module contains what you need to create assertions and test cases and combine them into test suites.

This module also provides infrastructure for implementing test controllers (which are used to execute tests). See Test.HUnit.Text for a great example of how to implement a test controller.

Declaring tests

data Test

The basic structure used to create an annotated tree of test cases.

Constructors

TestCase Assertion

A single, independent test case composed.

TestList [Test]

A set of Tests sharing the same level in the hierarchy.

TestLabel String Test

A name or description for a subtree of the Tests.

Instances

Show Test

Methods

showsPrec :: Int -> Test -> ShowS

show :: Test -> String

showList :: [Test] -> ShowS

Testable Test

Methods

test :: Test -> Test

(~=?) infix 1

Arguments

:: (?loc :: CallStack)

=> (Eq a, Show a)

=> a

The expected value

-> a

The actual value

-> Test

Shorthand for a test case that asserts equality (with the expected value on the left-hand side, and the actual value on the right-hand side).

(~?=) infix 1

Arguments

:: (?loc :: CallStack)

=> (Eq a, Show a)

=> a

The actual value

-> a

The expected value

-> Test

Shorthand for a test case that asserts equality (with the actual value on the left-hand side, and the expected value on the right-hand side).

(~:) :: (?loc :: CallStack) => Testable t => String -> t -> Test infixr 0

Creates a test from the specified Testable, with the specified label attached to it.

Since Test is Testable, this can be used as a shorthand way of attaching a TestLabel to one or more tests.

(~?) infix 1

Arguments

:: (?loc :: CallStack)

=> AssertionPredicable t

=> t

A value of which the asserted condition is predicated

-> String

A message that is displayed on test failure

-> Test

Creates a test case resulting from asserting the condition obtained from the specified AssertionPredicable.

Making assertions

assertFailure

Arguments

:: (?loc :: CallStack)

=> String

A message that is displayed with the assertion failure

-> Assertion

Unconditionally signals that a failure has occured. All other assertions can be expressed with the form:

   if conditionIsMet
       then IO ()
       else assertFailure msg

assertBool

Arguments

:: (?loc :: CallStack)

=> String

The message that is displayed if the assertion fails

-> Bool

The condition

-> Assertion

Asserts that the specified condition holds.

assertEqual

Arguments

:: (?loc :: CallStack)

=> (Eq a, Show a)

=> String

The message prefix

-> a

The expected value

-> a

The actual value

-> Assertion

Asserts that the specified actual value is equal to the expected value. The output message will contain the prefix, the expected value, and the actual value.

If the prefix is the empty string (i.e., ""), then the prefix is omitted and only the expected and actual values are output.

assertString

Arguments

:: (?loc :: CallStack)

=> String

The message that is displayed with the assertion failure

-> Assertion

Signals an assertion failure if a non-empty message (i.e., a message other than "") is passed.

type Assertion = IO ()

When an assertion is evaluated, it will output a message if and only if the assertion fails.

Test cases are composed of a sequence of one or more assertions.

(@=?) infix 1

Arguments

:: (?loc :: CallStack)

=> (Eq a, Show a)

=> a

The expected value

-> a

The actual value

-> Assertion

Asserts that the specified actual value is equal to the expected value (with the expected value on the left-hand side).

(@?=) infix 1

Arguments

:: (?loc :: CallStack)

=> (Eq a, Show a)

=> a

The actual value

-> a

The expected value

-> Assertion

Asserts that the specified actual value is equal to the expected value (with the actual value on the left-hand side).

(@?) infix 1

Arguments

:: (?loc :: CallStack)

=> AssertionPredicable t

=> t

A value of which the asserted condition is predicated

-> String

A message that is displayed if the assertion fails

-> Assertion

Asserts that the condition obtained from the specified AssertionPredicable holds.

Extending the assertion functionality

class Assertable t where

Allows the extension of the assertion mechanism.

Since an Assertion can be a sequence of Assertions and IO actions, there is a fair amount of flexibility of what can be achieved. As a rule, the resulting Assertion should be the body of a TestCase or part of a TestCase; it should not be used to assert multiple, independent conditions.

If more complex arrangements of assertions are needed, Tests and Testable should be used.

Minimal complete definition

assert

Methods

assert :: (?loc :: CallStack) => t -> Assertion

Instances

Assertable Bool

Methods

assert :: Bool -> Assertion

Assertable ()

Methods

assert :: () -> Assertion

ListAssertable t => Assertable [t]

Methods

assert :: [t] -> Assertion

Assertable t => Assertable (IO t)

Methods

assert :: IO t -> Assertion

class ListAssertable t where

A specialized form of Assertable to handle lists.

Minimal complete definition

listAssert

Methods

listAssert :: (?loc :: CallStack) => [t] -> Assertion

Instances

ListAssertable Char

Methods

listAssert :: [Char] -> Assertion

type AssertionPredicate = IO Bool

The result of an assertion that hasn't been evaluated yet.

Most test cases follow the following steps:

1. Do some processing or an action.
2. Assert certain conditions.

However, this flow is not always suitable. AssertionPredicate allows for additional steps to be inserted without the initial action to be affected by side effects. Additionally, clean-up can be done before the test case has a chance to end. A potential work flow is:

1. Write data to a file.
2. Read data from a file, evaluate conditions.
3. Clean up the file.
4. Assert that the side effects of the read operation meet certain conditions.
5. Assert that the conditions evaluated in step 2 are met.

class AssertionPredicable t where

Used to signify that a data type can be converted to an assertion predicate.

Minimal complete definition

assertionPredicate

Methods

assertionPredicate :: t -> AssertionPredicate

Instances

AssertionPredicable Bool

Methods

assertionPredicate :: Bool -> AssertionPredicate

AssertionPredicable t => AssertionPredicable (IO t)

Methods

assertionPredicate :: IO t -> AssertionPredicate

class Testable t where

Provides a way to convert data into a Test or set of Test.

Minimal complete definition

test

Methods

test :: (?loc :: CallStack) => t -> Test

Instances

Testable Test

Methods

test :: Test -> Test

Testable t => Testable [t]

Methods

test :: [t] -> Test

Assertable t => Testable (IO t)

Methods

test :: IO t -> Test

Test execution

Note: the rest of the functionality in this module is intended for implementors of test controllers. If you just want to run your tests cases, simply use a test controller, such as the text-based controller in Test.HUnit.Text.

data State

Keeps track of the remaining tests and the results of the performed tests. As each test is performed, the path is removed and the counts are updated as appropriate.

Constructors

State

Fields

• path :: Path
• counts :: Counts

Instances

Eq State

Methods

(==) :: State -> State -> Bool

(/=) :: State -> State -> Bool

Read State

Methods

readsPrec :: Int -> ReadS State

readList :: ReadS [State]

readPrec :: ReadPrec State

readListPrec :: ReadPrec [State]

Show State

Methods

showsPrec :: Int -> State -> ShowS

show :: State -> String

showList :: [State] -> ShowS

data Counts

A data structure that hold the results of tests that have been performed up until this point.

Constructors

Counts

Fields

• cases, tried, errors, failures :: Int

Instances

Eq Counts

Methods

(==) :: Counts -> Counts -> Bool

(/=) :: Counts -> Counts -> Bool

Read Counts

Methods

readsPrec :: Int -> ReadS Counts

readList :: ReadS [Counts]

readPrec :: ReadPrec Counts

readListPrec :: ReadPrec [Counts]

Show Counts

Methods

showsPrec :: Int -> Counts -> ShowS

show :: Counts -> String

showList :: [Counts] -> ShowS

type Path = [Node]

Uniquely describes the location of a test within a test hierarchy. Node order is from test case to root.

data Node

Composed into Paths.

Constructors

ListItem Int

Label String

Instances

Eq Node

Methods

(==) :: Node -> Node -> Bool

(/=) :: Node -> Node -> Bool

Read Node

Methods

readsPrec :: Int -> ReadS Node

readList :: ReadS [Node]

readPrec :: ReadPrec Node

readListPrec :: ReadPrec [Node]

Show Node

Methods

showsPrec :: Int -> Node -> ShowS

show :: Node -> String

showList :: [Node] -> ShowS

testCasePaths :: Test -> [Path]

Determines the paths for all TestCases in a tree of Tests.

testCaseCount :: Test -> Int

Counts the number of TestCases in a tree of Tests.

data Location

Constructors

Location

Fields

• locationFile :: FilePath
• locationLine :: Int
• locationColumn :: Int

Instances

Eq Location

Methods

(==) :: Location -> Location -> Bool

(/=) :: Location -> Location -> Bool

Ord Location

Methods

compare :: Location -> Location -> Ordering

(<) :: Location -> Location -> Bool

(<=) :: Location -> Location -> Bool

(>) :: Location -> Location -> Bool

(>=) :: Location -> Location -> Bool

max :: Location -> Location -> Location

min :: Location -> Location -> Location

Show Location

Methods

showsPrec :: Int -> Location -> ShowS

show :: Location -> String

showList :: [Location] -> ShowS

type ReportStart us = State -> us -> IO us

Report generator for reporting the start of a test run.

type ReportProblem us = Maybe Location -> String -> State -> us -> IO us

Report generator for reporting problems that have occurred during a test run. Problems may be errors or assertion failures.

performTest

Arguments

:: ReportStart us

report generator for the test run start

-> ReportProblem us

report generator for errors during the test run

-> ReportProblem us

report generator for assertion failures during the test run

-> us

-> Test

the test to be executed

-> IO (Counts, us)

Performs a test run with the specified report generators.

This handles the actual running of the tests. Most developers will want to use HUnit.Text.runTestTT instead. A developer could use this function to execute tests via another IO system, such as a GUI, or to output the results in a different manner (e.g., upload XML-formatted results to a webservice).

Note that the counts in a start report do not include the test case being started, whereas the counts in a problem report do include the test case just finished. The principle is that the counts are sampled only between test case executions. As a result, the number of test case successes always equals the difference of test cases tried and the sum of test case errors and failures.