For sure we can do data-driven testing using automated UI tests (Selenium, Cypress, WebDIO, etc.) but just because it gives us the option, doesn’t mean that we should it for all cases through UI only. Take an example where we visit any website to get a price quote on any policy — let’s say a medical policy, what do we do- we run our test by going through the same page(s) like select value from few dropdowns, select few checkboxes, and enter values in few text fields to get one final output i.e. the “price quote” of your medical policy- here the variation was only the “Test Data” that finally derive a certain output. Don’t you think that to test this business logic, the efficient way would be to perform API testing which is better maintainable and powerful?
As I mentioned in my previous post too, our UI (end to end) should be meant to confirm that user(s) can use our application in the way it’s intended to do so, perform interactions with it without hitting any issues and always work when performing any E2E transaction(s). On the other hand, our Unit and API test should test and cover the business logic part extensively.
Link to the previous post: https://testersdigest.blogspot.com/2020/04/defining-scope-of-our-end-to-end-tests.html
Comments
Post a Comment