Having business layer in automation

Today I like to write about having business logic layer in test automation.

Now days, I guess test automation is not something new in software testing. Whether your are testing desktop application, web application or SOA application, test automation plays an important role.

I've been writing quite a bit of automation code through out my software testing career. Of course, there are multiple different ways to write automation and it depends highly on the context of application.

What I've seen so far on writing test automation is pretty straightforward. You design your automation based on two separate purpose. Test execution code and helpers.

Test execution code basically represents the steps you need to go through to execute one test case. Normally, test execution code is a method starts with testBlahBlah...(). Helpers are more generic classes or functions that help test execution code. Things like until classes. String Helpers, DB Handlers, File Readers and etc.

I think these separation works out pretty well. I don't see much of problem with this way. Helper classes provide good flexibility to test execution code. Basically, you can mix and match helper classes based on any need of each test case.

And I thought of this business layer between test execution code and helper codes in automation.

Now if you see your one test execution code closely, you can easily tell that it contains three major part. The first one is setting up some situation and cleaning up or setting back to initial state for your test. The second one is executing what you're testing. (i.e. click submit button on your web page, sending request to the service, calling a function or etc. The last one is some sort of verification.

So, I normally have these three business logic classes in my automation, which means test execution code interact with these three business logic classes to do its operation.


So the automation flow is "Test Execution code" -> "Business logic lay class" -> "Helper classes".

The benefit you get from this design is pretty interesting. First, Test execution code can interact with the business logic layer without knowing helper classes, which means test execution code can call business logic layer class with sort of natural language. For example, we want to test user type something on discussion board goes to data base correctly. Now test execution code will do something like this.

public void testUserInputOnDiscussionBoard()
{
MyBusinessLogicClassForDiscussionBoard blc = new MyBusinessLogicClassForDiscussionBOard();
blc.login();
blc.goToDiscussionPage();
blc.typeRandomStringAndSubmit();

MyVerifyingClass vc = new MyVerifyingClass();
vc.verifyingDiscussionBoardInput(blc.getUserId(), blc.getRandomString());

blc.logOut();
}

This is pretty simplified version of it. But my point is that test execution code should not worry about how to login to the page, how to put some text on the page, or even how to check whether db is updated or not.

Second, I can keep the helper classes more generic. Since the business logic class will know what DB to use or what credential to use or what helpers classes to use,helper classes will not have business logic other than doing its own thing. DB Helper will only expose server name and DB name. And execute query code. You do not have to create some child class of some generic helper class.

Third, modifying test case is much easier. Since the business logic stays in one logical place, you can easily find places to change.