Automated Testing: Caplin Solution Overview, Part II

In Caplin we have found the solution to all of these problems mentioned Part I.

Caplin Trader software architecture has been developed following MVVM (Model View ViewModel) architecture with automated testing in mind. This architecture separates the user interface (View) from Model (Business Logic) with ViewModel which is a logical representation of User Interface.

The View is connected to ViewModel via data bindings (for displaying information) and command bindings (for actions like clicking a button). This separation of concerns helps with the automated testing a lot. For example if test View and Model separately then the links between them, we will be testing all parts of the system. Logically we apply the well-known Mathematics theorem; if A is equal to B and B is equal to C, then A must be equal to C.

But how do we achieve this? After all, many browser testing tools are testing the application via user interface such as Selenium. We need to use a tool which goes beneath the skin. Fortunately, Google’s  JS Test Driver can run on a browser testing only the ViewModel. Of course some fixtures will be needed to make it all work such as creating objects which make up the ViewModel, and the dummy objects which can imitate communication between the ViewModel and Model as well as between ViewModel and View.

In Caplin we have gone further and made our tests more readable by enhancing Jasmine Test Framework on top of  adapted Js Test Driver framework. Now our tests are quick to write, maintain, easy to read and understand and yet very fast to run. In our continuous integration system it takes only couple of minutes to run around 600 tests. If these tests were written using a tool which runs via user interface interaction such as Selenium (the best one of this type), it would have taken 13 hours to run them.

You will be forgiven to argue that this is a big leap of faith; by testing the parts separately, it is wrong to assume that they will work altogether. Remember we test the communication channels between these components as well. But just to be on the safe side, we employ just a few selenium tests to ensure that the software works end-to-end.

To recap how this is achieved:

• The company has committed developer and tester resources as this is a long term investment to ensure high quality products will get out of the door. It also recognised that this process may take some time. The developers and testers worked closely to implement the architecture and the fixtures.
• Maintenance became minimal once the automated testing framework and the application have the same architecture. The automated testing system is well understood by the developers so they update the tests while changing their code.
• The tests are now very quick to run with Js Test Driver and the in-house fixtures.

Sounds too good to be true? See the Part III to find a real example of how this applied to a finance software application.