Execution Model and Terminology

Jumi's test execution model is more expressive than for example JUnit's test runner's execution model, because Jumi allows arbitrarily nested tests, the same way as XML allows elements containing other elements. Due to this there are some differences in Jumi's terminology compared to other test runners.

Jumi's idea of what is a test starts from the assumption that the test results can be represented as a tree structure. In IDEs such as IntelliJ IDEA and Eclipse, JUnit's test results are typically shown as a tree whose leaves are individual test methods and whose other nodes are test classes and test suites. In Jumi all of those nodes are of the same type, i.e. each of them is a test whether it's a leaf node or a composite of other tests.

• In Jumi's API a test is uniquely identified by a TestId.

Also Jumi enables more ways of organizing test executions than JUnit. In JUnit each test method is executed individually, in a single step. In Jumi we have the concept of a run that consists of the execution of one or more tests, so that a larger test may consist of multiple steps. Each run has one top-level test execution, which in turn may contain other test executions, up to an arbitrary depth, the same way as an XML document has one root element which may contain arbitrarily nested elements.

If you run JUnit tests using Jumi, this ability of nesting tests is not being taken advantage of and the tests are run the same way as the JUnit runner does it (Jumi invokes the normal JUnit runner and just adapts the test results to Jumi's API). But if a testing framework supports Jumi natively, then it can take advantage of that ability. For example Specsy's isolated execution model lets you organize tests into a hierarchy of steps, improving readability and reducing duplication. And if somebody would implement Jumi support for Cucumber, then a Scenario would be a test and each Given/When/Then step that it contains would also be a test. The execution of a Scenario and all of its steps would be a run, thus expressing tests that consist of multiple steps.

• In Jumi's API the test execution is started using the SuiteNotifier.fireTestStarted method and you may call it multiple times, as long as you finally call TestNotifier.fireTestFinished on them in reverse order. The run concept is not visible in that API, but it can be seen in the test results API that is meant to be consumed by IDEs and build tools.

Below is a mapping of Jumi's terminology into JUnit's terminology.

Jumi	JUnit 4
a test	a test method, test class or test suite
a run	the execution of a single test method
a suite	a test run; the execution of all tests
RunVia class	RunWith class
Driver class	Runner class
SuiteNotifier and TestNotifier classes	RunNotifier class
TestId class	Description class