Specify and test your Isis domain model

If you decide to use Isis for more than just prototyping, then you'll probably want to formally test your domain model.

Isis integrates with two testing frameworks to help you, Junit and Concordion. Being able to test your domain models independently of the other gives you confidence when you move onto deploying your application as you prefer.

JUnit integration

Isis provides a JUnit test runner in order to integrate with JUnit. This is provided through its JUnit viewer.

For example, the following (based on the quickstart archetype) tests that a todo-item marked as complete cannot be marked as done once more.

@RunWith(IsisTestRunner.class)
public class ToDoItemTest {

    private ToDoItem toDoItem;

    @Before
    public void setUp() {
        toDoItem = toDoItems.notYetDone().get(0);
        toDoItem = wrapped(toDoItem);
    }
    
    @Test
    public void cannotMarkAsDoneTwice() throws Exception {
        toDoItem.markAsDone();
        try {
            toDoItem.markAsDone();
            fail("Should not been disabled");
        } catch (DisabledException e) {
            assertThat(e.getMessage(), is("Already done"));
        }
    }
    
    ...
}

The JUnit integration works by wrapping each domain object pojo in a proxy object. This proxy object is responsible for ensuring that the underlying pojo is interacted with in the same way as it would were being viewed in a regular Isis viewer.

For example, the call to markAsDone() action is transparently prefaced by a check to ensure that the action is not disabled. If the action is disabled, then the proxy throws the DisabledException.

It might seem a little odd - given that there is no UI - to call Isis' JUnit integration a "viewer". However, it does simulate what a viewer does, and fits into the same architectural layer as the other viewers.

BDD integration

Isis also provides an integration with Concordion, which is a BDD (behaviour-driven design) framework. This is provided through its BDD viewer.

The idea behind BDD is to allow a business stakeholder to describe the desired behaviour of the system in non-technical terms, and then to gain feedback )as to whether that behaviour has been implemented) in the similar way.

Concordion's implementation of this idea is to capture the specification using XHTML. This XHTML is then annotated by the developer inline with corresponding Java methods. Concordion's own JUnit test runner parses the XHTML in order to call these methods, which in turn interact with the system-under-test. Running the test also generates a copy of the original XHTML, this time annotated to indicate the result (success or failure) of the test.

Isis' integration with Concordion is to provide a pre-defined set of Java methods in a test case, by which the domain model can be interacted in a regular way. For example, using these methods the analyst can assert on the results of invoking an action, or, indeed, could assert that an action is disabled.

One caveat with Isis' Concordion integration: Concordion itself uses XOM, an XML library which is LGPL licensed. LGPL is incompatible with the Apache license, which means we are unable to explicitly include XOM as a transient dependency. You are free to use the Concordion integration, but you should be aware that doing so will require you to explicitly configure the use of this non-Apache dependency.