Automated Integration Testing and Why?
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 Selenium gained great popularity while it came to market, since its Free, Open 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
- No separate tool for testing the components (at least proprietary)
- Much robust testing compared to UI (since we test the components)
- 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, but since this is my first post in LinkedIn, please advise me if there are any mistakes or any misleading information so that I can correct myself and it helps others as well, as I know there are many great minds in linkedIn, I hope your comments is highly valuable.
I agree with the pyramid. All the product teams I know of have been shifting toward this model over the last several years.
Manager - Projects at Cognizant Automation Architect - TOSCA, Selenium, Appium, Mobility & Cloud - Selenium4 Grid |AWS |K8s |Docker
8 å¹´We may move to 'very rapid release cycle' and not otherwise. Or with some better jargon for faster release cycle through rapid automation.
Test Automation Consultant ?? Avid Tech YouTuber ?? Udemy Trainer ??
9 å¹´Glad you like it
React | JavaScript | Lead Frontend Engineer at JPMorgan Chase & Co. | Work Status: U.S. Citizen
9 å¹´Good information
Test Automation Consultant ?? Avid Tech YouTuber ?? Udemy Trainer ??
9 å¹´Giri Sabari Even the article says the same As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests