Modularization of test codes

blocksI’ll always be a fan of Lego. My kid too.

The fun part of playing with Lego is you can disassemble and turn to another toy. My kid turns an airplane to a car or a robot, like transformers. It’s all about imagination and criativity.

But when we grow up, we have to left those things away. But we have to use all we learnt to our life today.

Working on test automation, I have passed on several situations. Record & Playback, linear scripting, hard-coded parameters. We have always to think what we do to the code in the future. Just write and deliver? No, no. Someday someone will have to maintain the code and will suffer a lot.

I started with modularization on a project in my work. The entire project, monolithic, was separated in several components. The effort to do this was to make the software more malleable to deploy on clients. Or, in other words, a client needs an airplane and other client needs a robot.

I learnt a lot with this project, and obviously, have to do the same on tests. The concept of modularization tests is the reuse of code on other test classes.


As I suggest on this simple diagram, is to draw at least three layers of development.

The first layer is responsible for basic configuration, and some helpers. Is in this layer that you will create your connection to databases, open selenium servers, open applications with sikuli, and so on. In this layer will you open an csv file and read their contents and manipulate all logging of runtime, too.

Is in the second layer where your logical business of the Software Under Test (SUT) will be. Based on concepts of Page Objects pattern from Selenium, and Screen Objects Pattern from Sikuli, these layer will carry all what your application do. These classes will do the ‘integration’ between the tests and the application interface (web, mobile, backend, etc).

In the third layer, will be all the tests. All the logic of the test remains here. Is obligatory to reuse code from the logical business layer. In this layer, the test classes are written with a test framework, like Junit or TestNG.

You can have more than these three layers. The logical business layer could be divided accordingly to your SUT. But, at least, you need these three.

The pro of this approach is the reuse of code. In the diagram we see the business layer with classes being used  in more than one test classes. Think about the login process. Do you still rewrite code in every test script just to be logged on system? The cons of this is that test automator has to understand a lot of code programming and design to think like this way. But, at the end, I believe the pros beat the cons.

This kind of view can be used on another languages, instead the ones I work. If your language support object orientation, then will do the trick.

The modularization of testing code can make the roles on the life-cycle of software test well-defined. You can let a developer (with no test background) write the layer 1 and layer 2, and let a tester to write all tests in layer 3. The tester know more about the scenarios he want to achieve, and perhaps, don’t want to ‘waste time’ writing coding stuff.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s