Add flattr link to html output

[software/mutest.git] / README

.. |flattr| raw:: html

   <div style="width: 220px; height: 270px; float: right; margin-left: 1em; margin-top: 1em">
   <iframe width="220" height="270" style="border: none; outline: none" src="http://tools.flattr.net/widgets/thing.html?thing=1141711"></iframe>
   </div>


======================================================
|mutest| - A simple micro unit testing framework for C
======================================================

:Author: Leandro Lucarella
:Contact: llucax@gmail.com
:Version: 1.0
:Date: |date|
:Copyright: Leandro Lucarella (2008), released under the BOLA_ license
:Abstract: |mutest| is a micro `unit testing`_ framework for C (with some
    `C++ support`_). It's mostly an idea (it even comes with
    2 implementations_ of the idea!) with the goal of being easy to use
    (just write your `test cases`_ grouped in `test suites`_ and you're
    set) and so small and simple that you don't mind to copy the files to
    your project and just use it (i.e., no dependencies).

    The idea is simple: a source file is a `test suite`_, a function is
    a `test case`_ (special functions can be used for `test suite`_
    initialization_ and termination_), which can can have several checks_.
    Checks_ comes in 2 flavors, one that only prints an error, and one that
    terminates the current `test case`_ too. A (normally) automated `test
    program`_ run all the `test suites`_ and print some stats. It fails
    (returns non-zero) if any `test suite`_ fails.

    |flattr|



.. contents::
    :backlinks: entry


Installation
============

Download the `latest distribution tarball`__ and uncompress it.

__ http://proj.llucax.com.ar/home/mutest/releases/mutest.tar.gz

You can also download any release from the `releases directory`__ or get it
using Git_ directly from the `Git repository`__.

__ http://proj.llucax.com.ar/home/mutest/releases/
__ http://git.llucax.com.ar/w/software/mutest.git

You can get `this manual`__ too, or a `PDF version`__ of it.

__ http://proj.llucax.com.ar/home/mutest/manual.html
__ http://proj.llucax.com.ar/home/mutest/manual.pdf

To actually install |mutest| run::

    $ make install

Default installation path is ``/usr/local`` (because of that, you'll probably
need superuser privileges to install to the default location). You can override
that by passing the ``prefix`` make variable, for example::

    $ make prefix=/opt/mutest install

If you want to install just the docs, you can do::

    $ make install-doc

Or even ``install-readme``, ``install-html`` or ``install-pdf`` if you are too
picky.

If you want to install just one particular implementation_, to can use the
``install-c`` and ``install-py`` targets.


Quick Sample
============

You can find some samples in the sample__ directory.

__ http://git.llucax.com.ar/w/software/mutest.git?a=tree;f=sample;h=d8ad4dd9c3428fef5963107c82ab6a5e34ec6e00;hb=HEAD

This is an example taken from there. A simple *module* called `factorial.c`_
with its corresponding `test suite`_ (`factorial_test.c`_).

You can see some `C++ support`_ in the `exception_test.cpp`_ `test suite`_.

factorial.c
-----------

.. include:: sample/factorial.c
    :literal:

factorial_test.c
----------------

.. include:: sample/factorial_test.c
    :literal:

exception_test.cpp
------------------

.. include:: sample/exception_test.cpp
    :literal:


Concepts
========

|mutest| is about 4 simple concepts: `test program`_, `test suite`_, `test
case`_ and checks_. Well, to be honest you probably will need `test suite`_
initialization_ and termination_ too =)


Test Program
------------

A **test program** is the higher level unit of |mutest|. The test program is
the one in charge of running all your tests. Probably one of the more important
features of |mutest| is that you are not supposed to bother about the test
program. So, different implementations_ have different ways to tackle this.
Some need more or less interactions from your part, and each have their pros
and cons.

But this is all you need to know for now, for more details see how the test
program is implemented by your implementation_ of choice.


Test Suite
----------

A **test suite** is the higher level unit of |mutest| that you should
care about =). Is not much more than a way to group `test cases`_. Code-wise,
a test suite is a C (or C++) module (or compilation unit). Not clear enough?
A unit test is an object file (could be a shared object depending on the
implementation_). This module should have one or more `test cases`_ and it
could have any number (including zero) of initialization_ and termination_
functions.

A test suite, is inspected by the `test program`_ for `test cases`_ and
initialization_ and termination_ functions, and run them.

A test suite fail if one or more `test cases`_ fail, and it's skipped if one or
more initialization_ functions fail (or, depending on the implementation, if
the test suite can't be loaded at all).


Test Case
---------

A **test case** is just a plain function with a special signature and name.
A test case function name must start with ``mu_test``, and take no arguments
and return nothing. For example::

    void mu_test_something(void);

A test case (probably) only make sense if it has checks_. A test case succeed
only if all its checks succeed too.

Test are executed in an implementation_-dependant order, but usually the
default order is alphabetical.


Checks
------

Checks are assertions that a `test case`_ must pass (a boolean expression that
must evaluate to *true*). There are 2 big flavors of checks: **check** and
**ensure**. **check** just print an error (and *mark* the `test case`_ as
failed) and **ensure** halt the `test case`_ execution, jumping to the next
one.

For better `C++ support`_ there are check macros that assert that a specified
exception is thrown (instead of check for a boolean expression to evaluate to
*true*).

You can take a look at the reference_ to see the different flavors of check
macros in more detail.


Initialization
--------------

Sometimes you need to setup some environment shared between all the `test
cases`_ in a `test suite`_. You can use **initialization functions** for this.

An initialization function, like a `test case`_, is a plain C function with
a special name and signature. The name must start with ``mu_init`` and it must
take no arguments, and return an *error code* (``0`` being success). For
example::

    int mu_init_something(void);

All initialization functions are executed before any `test case`_, in an
implementation_-dependant order, and if one of them fail (returns non-zero),
the whole `test suite`_ is skipped immediately.


Termination
-----------

**Termination functions** are just like initialization_ functions, but they're
executed **after** the `test cases`_, their names start with ``mu_term`` and
they return nothing. For example::

    void mu_term_something(void);


C++ Support
===========

You can use |mutest| with C++, the only care you must take is that, because of
C++ `name mangling`_ (and |mutest| relaying on function names), you must
declare your `test cases`_ and initialization_ and termination_ functions as
``extern "C"`` (see `exception_test.cpp`_ for an example).

Checks_ become *exception-safe* when using |mutest| with a C++ compiler, and
2 extra checks_ designed for C++ get defined (`mu_echeck()`_ and
`mu_eensure()`_). They assert that an expression throws a particular exception.


Implementations
===============

There are 2 big groups of possible implementations that I can think
of: *static* and *dynamic*.

|mutest| comes with one implementation of each group.


Static Implementations
----------------------

Static implementations can be only written in C/C++ (or other language that is
link-compatible with C, like the `D Programming Language`_, but since one of
the main goals of |mutest| is avoid unnecessary dependencies, you probably
don't want to depend on an extra language/compiler to run your tests =).

The main advantage is better debugging support, because you can run the `test
program`_ in a standard debugger and see what happens with `test cases`_ very
naturally.

The main disadvantage is, the `test suites`_ must be figured out in
*compile-time*, usually using some kind of code generation (if you want to
avoid writing repetitive code yourself). There's also a limitation in the `test
case`_, initialization_ and termination_ functions names: they should be unique
for all the `test program`_.


C implementation
~~~~~~~~~~~~~~~~

|mutest| comes with a C static implementation. Only 3 files are needed:
``mutest.c`` (the *user-independent* part of the `test program`_), ``mkmutest``
(a bash script for generating the *user-dependent* part of the `test program`_)
and ``mutest.h`` (the header file that `test suites`_ should include).

You can copy this 3 files to your project or install them at system-level and
use them globally.

The procedure is simple, You should compile you `test suites`_, ``mutest.c``
and the generated output of ``mkmutest`` as object files and link them
together.

For example::

    $ cc -c -o mutest.o mutest.c
    $ cc -c -o test1.o test1.c
    $ cc -c -o test2.o test2.c
    $ mkmutest mutest.h test1.o test2.o | cc -xc -c -o runmutest.o -
    $ cc -o testprg mutest.o test1.o test2.o runmutest.o

Then you can run the `test program`_ invoking it with no arguments::

    $ ./testprg


``mkmutest`` Invocation
"""""""""""""""""""""""

This small script take 1 mandatory positional argument: the path to the
``mutest.h`` file. All remaining positional arguments should be object files
representing `test suites`_.


Test Program Invocation
"""""""""""""""""""""""

The test program can be invoked without arguments, but can take some extra
options:

``-v``
    Be verbose. This is accumulative, when you add extra ``-v`` you will
    get extra verbosity.

    By default, you just get failed checks_ printed. If you use a single
    ``-v``, a summary of failed/passed `test suites`_, `test cases`_ and
    checks_ will be printed. If an extra ``-v`` is used, you'll see the current
    `test suite`_ being executed. Another ``-v`` and you'll get the current
    `test case`_, and another one, and you'll get each check_.


Dependencies
""""""""""""

Even when dependencies are kept minimal, there always be a few ;)

To use this implementation you just need:

* A C compiler (you already needed that, so...)
* The ``nm`` program (from `GNU Binutils`_, included in virtually any \*NIX)
* The `GNU Bash`_ shell interpreter (also included in virtually any \*NIX)


Dynamic Implementations
-----------------------

Dynamic implementations, on the other hand, can be written in any language that
can access to shared objects. The idea is to inspect a shared object for `test
suites`_ and run them, without requiring any information about `test suites`_
at compile time.

There are several advantages in this kind of implementations. The dynamic
nature let you completely separate the `test program`_ from the user-written
`test suites`_ and you can choose at *run-time* what `test suites`_ to execute
by just selecting the correct shared objects. Also, `test case`_,
initialization_ and termination_ functions names only have to be unique in the
scope of the `test suites`_, because `test suites`_ are completely isolated in
separate shared objects.

But everything comes at a price, and the higher price to pay is
*debuggability*. It's a little harder to plug a debugger to a shared object.


Python implementation
~~~~~~~~~~~~~~~~~~~~~

This implementation is much simpler and elegant than the `C implementation`_.
Only 2 files are needed: ``mutest`` (`test program`_ written in Python_ using
ctypes_ module to access the shared object symbols) and ``mutest.h`` (the
header file that `test suites`_ should include).

Since both implementations provided by |mutest| share the same ``mutest.h``,
you should define the ``MUTEST_PY`` macro when compiling the `test suites`_ if
you will run them using this implementation.

As with the `C implementation`_, you can copy this 2 files to your project or
install them at system-level and use them globally.

The procedure is even simpler than the `C implementation`_: compile and link
you `test suites`_ as shared objects and then run the ``mutest`` program
passing the shared objects as arguments. For example::

    $ cc -c -fPIC -DMUTEST_PY -o test1.o test1.c
    $ cc -shared -o test1.so test1.o
    $ cc -c -fPIC -DMUTEST_PY -o test2.o test2.c
    $ cc -shared -o test2.so test2.o
    $ mutest test1.so test2.so

That's it.

``mutest`` Invocation
"""""""""""""""""""""

``mutest`` program takes `test suites`_ shared objects to run as positional
arguments. It accepts the same options as the `C implementation's test
program`__ and some extra options are accepted too:

``--verbose``
    Alias for ``-v``.

``-q``, ``--quiet``
    Be quiet (no output is shown at all).

``-s``, ``--search``
    Search for `test suites`_ (\*.so) in the current directory and add them
    to the list of `test suites`_ to run.

``-h``, ``--help``
    Show a help message and exit.

__ `Test Program Invocation`_


Dependencies
""""""""""""

As with the `C implementation`_, some minor dependencies are needed:

* Python_ (2.5 or later)
* The ``nm`` program (from `GNU Binutils`_, included in virtually any \*NIX)

You will need a C compiler for building the `test suites`_ too, but technically
is not needed by |mutest| itself ;)


Reference
=========

``mu_check()``
--------------

Synopsis
    ``mu_check(expression)``

Description
    Check that the ``expression`` evaluates to *true*. Continue with the
    `test case`_ if fail.

Availability
    Always

Example
    ::

        void mu_test(void)
        {
            mu_check(5 == 4); /* fail */
            mu_check(5 == 5); /* excecuted, pass */
        }


``mu_ensure()``
---------------

Synopsis
    ``mu_ensure(expression)``

Description
    Check that the ``expression`` evaluates to *true*. Interrupt the `test
    case`_ if fail.

Availability
    Always

Example
    ::

        void mu_test(void)
        {
            mu_ensure(5 == 4); /* fail */
            mu_check(5 == 5); /* not excecuted */
        }


``mu_echeck()``
---------------

Synopsis
    ``mu_echeck(class, expression)``

Description
    Check that the ``expression`` throws a specific exception ``class`` (or
    subclass). Continue with the `test case`_ if fail.

Availability
    C++ only

Example
    ::

        #include <stdexcept>

        extern "C"
        {
            void mu_test(void)
            {
                mu_echeck(std::exception, true); /* fail */
                mu_echeck(std::exception,
                        throw std::runtime_error("!")); /* excecuted, pass */
            }
        }

``mu_eensure()``
----------------

Synopsis
    ``mu_eensure(class, expression)``

Description
    Check that the ``expression`` throws a specific exception ``class`` (or
    subclass). Interrupt the `test case`_ if fail.

Availability
    C++ only

Example
    ::

        #include <stdexcept>

        extern "C"
        {
            void mu_test(void)
            {
                mu_eensure(std::exception, true); /* fail */
                mu_echeck(std::exception,
                        throw std::runtime_error("!")); /* not excecuted */
            }
        }


About
=====

This manual was written using reStructuredText_.

.. Use section numbers
.. sectnum::
    :suffix: .

.. Internal Links (aliases):
.. _`test suites`: `test suite`_
.. _`test cases`: `test case`_
.. _check: checks_
.. _implementation: implementations_


.. External Links:
.. _BOLA: http://blitiri.com.ar/p/bola/
.. _`unit testing`: http://en.wikipedia.org/wiki/Unit_testing
.. _`name mangling`: http://en.wikipedia.org/wiki/Name_mangling
.. _`D Programming Language`: http://www.digitalmars.com/d/
.. _`GNU Binutils`: http://www.gnu.org/software/binutils/
.. _`GNU Bash`: http://www.gnu.org/software/bash/
.. _Python: http://www.python.org/
.. _ctypes: http://docs.python.org/library/ctypes.html
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
.. _Git: http://git.or.cz/


.. Substitutions:
.. |mutest| replace:: *mutest*
.. |date| date::

.. vim: set filetype=rst expandtab shiftwidth=4 softtabstop=4 :