Site Loader
Auckland, New Zealand
In this post we are going to discuss about automated integration testing. So far in ExecuteAutomation.com we have been talking about automated functional testing using testing tools like These functional testing tools addresses the UI (User Interface) testing of applications. There are many sites which exclusively discuss about these above mentioned tools and we have covered almost all these tools as much as possible in many videos (140+) and articles (200+) As the name of the post is, we are going to discuss on Integration testing of application, and the reason behind the sudden paradigm shift on my post is THAT’S WHERE THE INDUSTRIES ARE HEADING TOWARDS !!!

QTP Era

Gone are those days where automation engineers where writing code (to be precise “scripts”) using QTP (Quick Test Professional) tool, where they just record and playback their test by adding some (or more depends) logic for descriptive programming and test their applications. After the dotcom boom, many companies started their focus on web applications and web based services rather just a standalone applications, hence Seleniumgained great popularity while it came to market, since its FreeOpen Source and best tool for web application than its peer QTP (as it supports multiple browsers and so many other reasons).

Rapid Release

As that said, now most companies like Microsoft, Google, Facebook, Mozilla and many more are migrating their products towards rapid releases, While this allows faster time-to-market and user feedback, it also implies less time for testing and bug fixing. Since initial research results indeed show that rapid releases fix proportionally less reported bugs than traditional releases. As Rapid releases are adopted by many companies not just the above said, the fragile UI testing is not going to work out for long run.

Problem with UI automation

I am in automation testing field for more than 9+ years now and most of the time we see people complaining each other’s (QA and Dev), I see my managers or my peers complaining about the automation that we do, since it works well on Monday and bursts on Wednesday where we in turn complain developers that they changed something which broke our automation. That happens mostly if the application is not built by keeping automation testing in mind, but some project I worked are very automation friendly and they report us if there happens any change in UI and we take care of beforehand (but its rare case).

Will Integration testing address the problem?

Well, of course not the UI issue, but, the trend in today market seems to be shifting their focus from UI to components level which are deep into the program they are building, by doing this they find themselves following advantages
  1. No separate tool for testing the components (at least proprietary)
  2. Much robust testing compared to UI (since we test the components)
  3. Less overhead with maintaining the code (at least not as fragile as UI)

    Automation testing pyramid

    The automation testing pyramid of current trend (Agile methodologies) looks something like this, you can find from here as well As you can see above, the level of automation testing done for UI is far less than the Unit and Integration testing.

    How to do Automated Integration testing ?

    There are many open source tools available for doing automated integration testing and they can be used for unit testing as well, I have listed some which are very interesting to me
  • Specfor
  • Fluent Assertion
  • Fluent MVC (for Asp.Net MVC applications)
  • Moq (mocking frameworks)

    Finally

    I believe the trend of rapid release cycle is nowhere going to stop in near future, may be, it can go a step ahead to very rapid release cycle, but not the other way around, hence its very important for all of us to start focusing more white box testing rather just the black box UI automated testing. Hope you like this post !!! Thanks for reading and post and share your comments if there is anything missing or misleading
Thanks, Karthik KK

Post Author: Karthik kk

One Reply to “Automated Integration Testing and Why?”

  1. I think you missed the point/reason that Unit Tests become more of the pyramid. It is due to their purpose/focus of type of test. Unit Tests are more atomic/granular in scale to the other levels, thus you will have more one-to-one relationships with a line of code or a logic block. Thus because of this you naturally will create more of them. As you go up the pyramid the granularity of the tests become more conglomerations of actions, thus fewer overall “tests” are created because the tests themselves become more complex.

    At the top the GUI level tests are even more complex and less granular in form/shape. They test larger chunks of code/logic and thus do not need to be as many. The problem with maintaining them is because majority of people don’t know how to build modular and maintainable harness code (testware) that is the automation framework itself. This is due to the B.S. of tool vendors who sold the Record/Playback (old saying was Capture/Replay) automagic story.

    Don’t get me wrong I support the ideals of pushing testing (and thus some type of automation of it) upstream to the Unit level, but a comprehensive model needs to be employed. Don’t ignore GUI level tests, but be smart about how you implement them.

Leave a Reply

Your email address will not be published. Required fields are marked *