PackageDescription: Dakar Testing(Bundle)


Dakar Testing

Last published: August 20, 2007 by 'karsten'


Dakar Testing is a completely new framework to test your application with
unit-tests. It adds a link between a method and its tests.



INTRODUCTION
=============

Whereas unit tests are known to be part of the best practices in
software development, they are seldom used because of the difficulties
to create them and maintain them. In fact, when writing software,
developers often have to switch between the development process and
the testing process which is kind of disturbing. The aim of this application
is to improve the developer's workflow allowing more efficiency and less
disturbance.




FEATURES
=========

Here are some features brought by this system:

\subsection{On the programming side}

When the developer is browsing his classes, he might want to have more
information about the code and the associated tests.

\paragraph{Tests} The developer should be able to immediately see what
are the tests associated to the current code (a package, a class or a
method). He might want to know what are the states of this tests, too
(more on those states later). It may be interesting to highlight the different
tests with meaningful colors like red and green or icons depending on the state.

\paragraph{Code state} When browsing source code, the developer should
not do anything to see the state of his code. If the code fails its
tests, or if the code has not been tested, one should notice this
without even looking for this information.

\paragraph{Same place} The developer should be able to go from a
method to one of its tests in a second and back to its method with the
same efficiency. The same browser should be used.

\paragraph{Framework abstraction} The developer shouldn't mind about
subclassing TestCase or giving a name to its test class, he just wants
to write tests. This should be abstracted and eased.

\paragraph{Invalidate tests} When one modifies a class or a method,
lots of tests can be affected by this change. This tests have to be
invalidated and the user has to know that some tests are pending and
need to be run again.

\paragraph{No aggression} Sometime, when a developer modify a method,
he knows that some tests will fail (maybe because other methods have
to be modified, too). In this cases, he doesn't want to see an
aggressive dialog box telling him that tests have to be run again. He
doesn't want the tests to be automatically launched, too. What he wants
is a discrete remainder telling him that some tests will have to be
run later when he is ready and this remainder should not slow him down
in his process of writing code.


\subsection{On the testing side}

When the user wants to write or run tests, some things have to be
ready for him.

\paragraph{Writing tests in place} Developers very often switch from
code writing to test writing and back. This should be eased by
allowing them to write tests and code in the same browser and switch
rapidly (without having to find the right package, the right
class...).

\paragraph{Association} When browsing a test, it should be possible to
link it to one or more methods that are stressed by this test. This
link can be computed automatically using type inference but this is
not the subject of this paper. Tests should be attached to the class
when they are not attached to any method.

\paragraph{Simple automatic association} When browsing a method, it
should be easy to add a test that stress this particular method. In
this case, a meta link should be automatically inserted between the
two.

\paragraph{Running} Launching all tests of a class or of a method
should be very easy. No need to look for the right test class nor the
right package.

\paragraph{Test suite} It should be easy from a model class or package
to create new test suites and launch the one you want.

\paragraph{Event handling} It might be interesting for an object to
know when a test is run and what is his new state. An event handling
should be installed on tests that will send events to objects that are
registered. This events should contain the new state of the test.

\paragraph{Randomization} The test order should be randomized to
detect side-effects (not implemented yet but should be easy).

\paragraph{Known to fail} Sometimes, a developer knows that a test fails
because a method is not fully implemented for example. The test is
useful to remind the developer to finish the implementation. However,
it is very annoying that this failure is mixed with real failures. It
slows down the process of debugging and bothers the tester. It should
be possible to mark those kind of tests and attach a little
description to them. This tests should be easily distinguished from
the others.

\paragraph{Duration} Often, before launching a test suite, one would
like to know how many time it will take to run all this tests. This
can be achieved by storing along with each test the last duration of
this test. Then, before running or while running a suite, the system
can supply some estimated time.

Here is a description of the contained packages:

- TestModel: this is where the model is stored. There are classes like Suite
and TestMethod.
- Controller: classes managing associations between model and tests. How
we store things as source code is also here.
- InterfaceExtension: enhancement to the refactoring browser to link methods
and their tests and manage suites and test cases.
- SmallBrotherIntegration: responsible for detecting/handling modifications in
your classes, methods...