When we talk about automated testing, what comes first to the head? Tests that simulate the user using an application, through the UI (User Interface)? Unit testing?
In this post, we’ll show you the levels of automated testing within Agile and how to improve your company’s test automation strategy with a focus on unit testing.
In companies that are starting to work with automated testing, it is common to see the use of record-playback tools such as Selenium IDE to create test scripts validating end-to-end scenarios in an application through the UI. These tests are also called Acceptance Tests.
Tools such as these have greatly facilitated the creation of these tests, allowing even a user to record a test without requiring programming skills. Paid solutions, such as IBM, HP and Microsoft, also offer such tools.
Unfortunately, it is also common to record hundreds of tests that navigate the UI, only realizing that something is wrong when a new field is included in a screen, or when the identifier of an element is changed, for example. In the medium / long term the problems arise: the maintenance cost becomes high, the tests take a long time to run (increasing build time) and give feedback on the system, many tests fail due to false negatives, etc. With this, the team ends up losing confidence in the tests and often failing to run them.
The importance of unit testing in agile
In companies that have agile teams, unit tests (and also TDD – Test Driven Development) already help us a lot in this situation. When we have a fair amount of unit testing for a system, it becomes less necessary to automate such exhaustive testing by the UI. Drive tests are easy to maintain, very effective for testing limit values or possible combinations of deviations within the code, and run extremely fast, giving us good feedback on our system in a short time. However, by definition, we are testing isolated component behaviors, so that at one time or another we should test the integration between them, right? So, do we then create a test that navigates through the UI to validate this? No!
Pyramid of Test Automation
In his book Succeeding with Agile, Mike Cohn describes the concept of the Test Automation Pyramid.
Pyramid of Test Automation According to Cohn, an efficient strategy of automated testing should contemplate tests at three levels: Unit, Service (Integration) and UI. At the base of the pyramid, we have a lot of unit tests, which should be the basis of a good automated testing strategy. At the top, a small amount of UI tests, just to avoid the problems we discussed earlier. In between, we have a fair amount of service testing, which can also be called integration tests, API tests, etc. Cohn, in the article The Forgotten Layer of the Automation Test Pyramid, comments on the importance of this level of testing and its role in filling the gap between unit and UI.
As we could see, the basis of the test pyramid are unit tests! The TDD is the practice to develop the unit tests.
TDD is a “programming practice” that results in a suite of unit tests, where such tests are a side effect and not the goal itself .
In the application of practice of TDD is guided by three basic steps, used in the development of the unit tests, and consequently of the source code of the application:
- A failed unit test is developed to demonstrate that the existing code base does not yet contain such an implemented feature;
- Once the failed unit test is produced, the production code is produced to get the executable test passed and passed;
- As the test passes, code is refactored to wipe and eliminate duplicates to make the source code legible and improve the design.
Tests in the service layer basically test the application services, “below” the UI. This approach prevents any test, other than the unit test, from running directly through the user interface. So instead of running exhaustive tests validating all business rules across the interface, we can do tests below the UI. This type of test has been very important, since many applications nowadays have Web and Mobile interfaces (smartphone, tablet), and it is necessary to separate the interface from the logic of the application. Martin Fowler refers to these tests as Subcutaneous Tests.
Within Agile, we can do these tests to validate the criteria for accepting stories, for example. A good approach is the use of BDD (Behavior-Driven Development).