Sureassert Exemplars enable Declarative Unit Testing. Traditionally, Java unit tests are written as classes containing methods that execute code on an “object under test”. The test code fundamentally does three things:
- Create or otherwise retrieve an object (the “object under test”),
- Execute a method on the object under test with typical inputs, and
- Assert one or more expected results on the method’s returned value, thrown exception, the object under test’s state, and/or the state of some other affected object.
It typically might also:
- Perform some initialization and/or clean-up; although this is more typical and necessary within integration and functional test classes rather than unit tests as these more often deal with resources external to the object under test;
- Setup stubs or mocks to force external dependencies to behave in a manner determined by the unit test, and
- Assert the behaviour of the method under test, e.g. what methods have been invoked by the method under test and in what way.
Exemplars are used to define the “whats” of a unit test as per above, i.e. the object under test, typical inputs, expected results, stubs, etc , are specified declaratively within the Exemplar. An Exemplar Execution Engine then executes the Exemplar against the specified object and method under test.
Sureassert UC is such an Exemplar Execution Engine. You specify Exemplars within your code by annotating your project’s methods, and it executes them. This will usually obviate the need to write unit test classes for any code already covered by Exemplars.
Declarative Unit Testing has further benefits above obviating the need to write coded tests. As they are declared on your methods, they effectively form part of the method contract. As such they can be thought of as an extension to the worded contract defined within javadoc, defining exemplar inputs and outputs for your methods. The engine effectively enforces these contracts.
Furthermore, by formalizing unit test structure across your project, Exemplars can simplify the process of unit testing considerably, can leverage each-other, and better facilitate both test-driven-development and contract-driven-development.
Previous Page | Next Page | Table of Contents