Architectural overview

Verifier is an integrated test framework for unit and acceptance testing BladeRunnerJS apps. This topic explains the key concepts and architecture behind Verifier.

Verifier consists of three major parts:

  • An execution engine for unit tests based on Google's JsTestDriver.
  • A test library, that extends Jasmine, and provides the features required for writing Given-When-Then style acceptance tests.
  • A set of pre-written fixtures that acceptance tests can use to exercise the underlying code being tested. Some of these fixtures are generic, some are specific to the Caplin HTML5 libraries

We will look at these in more detail in the following sections:

Test Execution Engine

Verifier uses JsTestDriver to run tests. The diagram below shows the structure of JsTestDriver with some Caplin enhancements.

Verifier architecture diagram

JsTestDriver is a Java program that starts an embedded web server (JsTestDriver server).

On startup, JsTestDriver reads a configuration file (JsTestDriver.conf).The configuration has several parts including two main parts:

  • Load section — Details all the files that should be loaded in the browser to run the tests
  • Test section — Details the tests to be loaded and run automatically once the server is started and all files loaded.

When the JsTestDriver server starts it opens any browser(s) the user has specified, loads the code into the browser and runs the tests.

When the test run is complete the results are output to file in a standard JUnit XML format that is understood by most Continuous Integration systems.

Verifier wraps and extends JsTestDriver with the following enhancements: 

  • We have added the BladeRunnerJS bundlers as JsTestDriver plugins. This means that instead of listing each file to load in the JSTestDriver.conf file the bundlers search for all the required dependencies and automatically load them. All you have to do is place your test files in the appropriate place within the blade directory structure. 
  • Simple command line execution of tests:

    • brjs test ../apps/myapp UTs
    • This command locates and executes all unit tests under the given directory. It is simple to execute a subset of your test suite by using the appropriate directory in the command.
  • We automatically produce HTML test reports, making it easier to interpret your test results.

Given-When-Then style acceptance tests

Given-when-then style acceptance tests allow business owners to express the required behaviour of a system in a natural language style. This black box testing expresses what a system should do  (rather than how it should do it). Fixtures translate the test into a set of method calls on the underlying system. Generally developers are responsible for writing the fixtures. Below is an example test for a GUI component.

it("displays a confirmation message when trade is confirmed by server", function(){
  given("test.continuesFrom = 'client sent an accept message to server'");
  when("trading.eventReceived => 'TradeConfirmation'");
  then("tile.model.state = 'TradeConfirmed'");
    and ("tile.model.confirmMessage = 'Your trade has been confirmed'");
});

This allows those not familiar with the code of the component to write tests and new developers to understand the existing functionality. This style of testing is called BDD or Behavioural Driven Design.

Acceptance tests are run using the JsTestDriver based execution engine. You can tell verifier to run ATs rather than UTs like this: ./brjs test ../apps/myapp ATs

Fixtures

A fixture is a bridge between the test and the code that is executed by the test. When developing your BladeRunnerJS components you will be use our Caplin libraries. Where appropriate we have added fixtures to each of the libraries to help your testing, for more details refer to the fixture reference.