Integration Testing:How to automate the core of your application?
What integration testing means can be different depending on your architecture,but for our discussion I would like to focus on role of integration testing in a service oriented architecture.For this discussion integration tests are primarily tests that do not require an actual application or browser to be launched.The tests should be able to run in a non-GUI environment.This is a testing layer that resides almost between unit testing and GUI testing.Depending on your architecture,this can be also the layer where your application API(public or testing) are defined and can be used to do significant business logic testing.
Why do integration testing?
Integration testing like all things in testing is not the ultimate solution,but part of an overall solution.Here are some key advantages
- More stable than GUI tests
- Useful in writing precise component level tests.
- Drives better code design
- Tester understands the internal workings of application allowing better writing of test cases
- Easy to integrate in a continuous integration environment
- Test the core of your application agnostic of UI.If your application has a large business logic area and a light UI layer,this is the right layer to do your automation.
What about the disadvantages?
- Testers need to understand code and at times also write code.
- Continuous integration framework though not necessary is nice to have to take full advantage of integration testing.Significant effort is required to get the whole system going.
Rather than discuss the technical details of how to do integration testing,I would like to share my experiences with two approaches that I took and my thoughts about it
Approach 1:API layers or interface layers
This was a Java application so there was no traditional API layer,but while programming there were some natural interfaces created by the application.But since they were written keeping the application and not testing needs in mind(which infact is not a bad thing,if you think about it).
The tests still need to be written using some framework.I used JUnit but in hindsight,I think TestNG is a better choice for integration testing.Since the API’s are not written for testing,Lot of time goes into understanding the limitations and actual functionality of the interfaces.This improved my understanding of the application but decreased my output in terms of actual testing to be written.Also when a functionality is not exposed,writing of the interface or exposing the functionality through existing interface falls on tester’s shoulders and can be easy or hard depending on various factors.The tests were not plugged into a continuous integration architecture and hence keeping track of it ,fixing as soon as it failed turned out to not so easy task.
Approach 2:The other approach was using FitNesse.While FitNesse as a tool has it’s own advantages and disadvantages,from point of integration testing here are some of the advantages
- Tests easy to write in Wiki format.
- Drives better design of code when “fixture” code is getting written.
- Tester gets better understanding of application writing component level tests.
- Quick feedback and easy to see test results helps in finding bugs quickly.
While not exactly disadvantages,some of the pain points are
- Developers/Testers need to write additional code to expose functionality for testing.
- Working around FitNesse issues is not always straightforward.
- Learning FitNesse takes time and effort.
- Writing code to test actual code is a change that entire organization has to learn to incorporate into planning.
Having said all of this,Integration testing becomes more important if you think about multiple browsers and different mobile devices which even though have separate UI will be hitting the same business logic.Any good integration testing strategy will give testing team more confidence and will be as important as any UI automation strategy moving forward.
Curious what is a good integration testing strategy for your organization.Apexon can help you out.Contact us or follow us on twitter
