Unit Testing and Session Testing

What’s the Difference?

The key difference between unit testing and session testing is one is performed in-situ and the other is performed ex-situ. When performing a Unit test the inputs provided by the testing environment are simulated so that the outputs can be predicted and confirm (or disconfirm) that the component behaves as expected. By contrast – Session tests simulate user input on a final user interface in it’s typical environment. 

Why Bother?

The reason for unit testing and session testing is to verify that a complex system will perform consistently. With large systems it’s inconvenient to manually test every component every time a change is made anywhere in the system however it’s also very important as a change in one part of the system may break another (seemingly unrelated) component. By writing automated tests for the system the test will verify proper behaviour of both the new component and it’s surrounding environment. Both before an object is integrated with the system (Unit Test) and after it is integrated (Session Test).

But How Do I…?

The methods for setting up Unit Tests or Session Tests depends greatly on the programming language and environment which your using however there are some general rules.

Setting up Unit Tests

Generally speaking a Unit Test should be performed on a component before it is to be integrated with the rest of the  system. There is an odd trade off whereby Unit Tests are easier in Native environments but more difficult in Online environments.

For Backend Components

For backend components – running unit tests often means pulling together the object being tested, a simulated environment for it and the defined tests / assertions for that environment. Once the simulated environment and tests are in place any number of different implementations can be run through the tests to verify which elements work as expected and which may need further adjustment for performance or functional reasons.

For Online or Visual Components

Online systems and visual components can often be harder to develop Unit Tests because it can be more difficult to set up the simulated environment and tests. However; scripts can be loaded on a dummy page with only the components needed by the script without the rest of the page components such as headers and footers in the way and then a web automation toolkit or other UI automation toolkit can run over the tests and confirm the expected results are achieved. However – often the results are intrinsically visual in some way – this tight linking with a visual environment can make validating certain assertions less trivial.

Setting up Session Tests

Once Unit Tests have been completed on all the individual components of a system they are deemed ready to be used in a Session Test. Contrary to Unit Tests however a Session Test is easy for a Web language but more challenging in a Compiled scenario.

For Backend Components

Often once a back end component has been unit tested it is deemed to follow the rules it has had applied to it however in a ‘real world’ scenario the inputs provided to it may be somehow corrupted or non-standard. That’s why it’s important to design Session Tests in a way that each of the backend components has all of it’s components used even if they’ve already been tested as part of a Unit Test.

For Visual / Online Components

Session Tests are the best way to test a Visual or Online component because a Session Test is designed to mimic an end user through automation of the interface the user would typically use. For websites – this is often accomplished by using CSS style selectors to find elements which are expected to be on a page and then using them in the same way a user would. There are some challenges to this approach however since a CSS selector can be used to find an element which is actually hidden on the page. If this is done then a test can be designed which ‘works’ but a user would not normally be able to perform the same action.