In my previous post, I discussed the difference between tests that target code versus those that target an API. A subset of the second category are automated tests for a web/mobile interface that mimic user behavior and validate the rendered responses, using Cucumber/Selenium, Cypress, or any other stack. These are typically written and executed as end-to-end tests, in that they require a production-like setup of the backend; but that needn’t be the case. GUI tests can turn into true component tests if they target the browser, but with a fully mocked backend. In a complex microservices architecture, it makes good sense to do so. In this article, I will highlight the motivation for writing those tests, and in a follow-up, I will give tips and examples on how to do so with the Karate framework. Feel free to dig into its excellent document if you can’t wait.
Separation of Concerns Between Frontend and Backend
Traditionally, in the world of JSP and JSF, the backend of web applications would contain mostly display and rendering logic, on top of handling all business rules. With so much server-side rendering, you had no choice but to spin up the actual backend code if you wanted to automate a user scenario in the browser. Without the backend, nothing much would work.