I have written in my previous blog about how we need to distribute our tests across the testing pyramid for reasons which i have explained in the previous blog. This particular post is focussed on how we ought to design our tests across the higher levels of abstractions which includes the UI test and API tests.
in Java using RestAssured library. The content of this post is an expression of my experience and observation and I am happy for other people to share their experiences.
1. Maintenance cost is even higher: I have already established in my previous post how expensive these high level tests could be.
- Testers and back end developers contribute to the API Tests while front end developers contribute to the UI Acceptance Test.
- Testers and front end developers contribute to the UI Acceptance Tests while backend develops would write/maintain the Java API Tests.
This is bad as we have just reintroduced silos into the team. Another side effect is that the definition of “Done” becomes blurred. We expect that the definition of “Done” to be when all code has been written, tested, deployed and signed off by the product owner. However when we have two separate test suites, back end developers can write the Java API test as soon as the back end code is completed and provided the test are passing, the team is tempted to split stories in back end stories and front stories over time.
3. Higher chances of duplicating test scenario in both suites: For the reasons that have been described above, I have observed that the chances for similar test scenarios to be implemented in the UI Acceptance tests as well as in the API test suite is highly increased. This is because when the team doesn’t work together on the tests and assumptions are made, most likely than not, a team that cares about test coverage would try to write as many test as possible which ends up in having the same scenarios implemented twice. Similarly, it is a lot easier to introduce gaps into the testing, this occurs for instance if a backend developer assumes a particular test should be written as part of the front end test and this is not communicated; the other person that is supposedly writing the front end test might not write the test for similar reasons.
In other to reduce the chances for some of these problems that i have observed, I would always advice for a single code base and single language for API Test and the UI Acceptance Test.
I worked with a client a couple of years ago, and before i joined the team, the set of their API Tests and UI Acceptance Tests was as described above. The problem was even worse at the time, as the UI Acceptance tests were considered an optional set of tests.
On joining the team, i got everyone together so that we could discuss how we were doing tests as a team and where we would like to be. It wasn’t an easy task but the team decided to use a combination of Spock (for defining test scenarios), Geb (a browser automation tool based on WebDriver) and Rest Assured.
- Groovy: The base language used in the test suite was Groovy which is a JVM based language; this felt as a middle ground for both java developers
or any other scripted languages.
- Geb: This library was the main reason we tilted towards Groovy, Geb has a nice syntax that is very jQuery like and this is the reason we decided
to use this language.
After we had adopted these set of tools, below are some of the advantages that we experienced:
1. Creation of Test Automation scripts became an atomic task in that “the automated tests have been written” meant that both front end and back end tests have been thought through
and implemented accordingly.
2. Reusability of set up data came naturally, as we had a single suite of test; hence a singular test set up.
3. Reusability of code including helper class, page object and api wrappers.
4. The feedback was much faster as we had a singular test suite and all we had to do was run one set of test.
5. Singular source of Truth for Test as source of System Documentation.
I really hope when team are just about to start your next set of tests, maybe on a brand new project or a rewrite of an existing test suite; you would think about some of the points discussed above, make sure your api tests and ui tests are in the same language and within the same project.