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.
- 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.
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.
The adviceIn 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.
- 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.
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.
Reusability of set up data came naturally, as we had a single suite of test; hence a singular test set up.
Reusability of code including helper class, page object and api wrappers.
The feedback was much faster as we had a singular test suite and all we had to do was run one set of test.
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.
You Might Also Like
January 6, 2017
January 6, 2017