It's common thinking that the tests that use the UI are generally slow and brittle, and difficult to write and maintain. Nevertheless, UI testing is a practice that is useful to consider when designing the test strategy for developing a software.
A few years ago, Mike Cohn defined the Agile Testing Pyramid in his book Succeeding with Agile: Software Development Using Scrum, which describe the types of tests, and how many are required for each type of implement action to be effective:
- Unit tests: These are the basement, they are quick to run, can be exhaustive, can cover all the classes in the app, and we should write as many as possible.
- Service tests: In the middle, these are connected to a service layer, the RPN calculator in our simple case. This layer offers all the features or services to the UI.
- UI tests: At the top, this uses the elements of the app as if it were a user. The problems of the fragility and slowness of this kind of test remain, but still, they carry value, and, if written in a clean way, and if written only for the ones that touch as many parts as possible, they give us the confidence that all the layers are connected together correctly.
The following diagram depicts the testing pyramid:
