I have been confronted with end-to-end(e2e) front-end testing in my enterprise project for the last couple of months and found a few practical tips worth developers' attention before starting their front-end testing. Let me share one of them in this post.
Split your e2e testings into interactive testing and scenario testing
Interactive testing (or integrated testing) means any behavioral testing within a specific page, such as opening/closing a modal window and binding input data.
On the other hand, scenario testing ensures successful page transitions and data consistency between pages. For example, a purchase scenario testing starts from the Top page a user enters to the Thanks page where the same user exits.
1st Reason: Avoid Flaky Results
There are two main motivations for splitting these two tests. We can avoid flaky results and separate SSR and CSR pages.
First, it would be too challenging to avoid flaky (unstable) behaviors if you mix both interactive and scenario testing into one extensive testing.
In general, scenario testing tends to be flakier than interactive testing because it involves page transitions and data transfers, while interactive testing involves only one or a few components.
Moreover, it is usually not until the finished phase that the scenario testing starts to pass stably. In contrast, interactive testing will pass as soon as developers finish implementing a few components, and they are less susceptible to external data and web services.
2nd Reason: Mock data v.s. Real data
Lastly, interactive testing goes better with mock data because we want to test a variety of component behaviors including both normal and edge cases. Most e2e testing framework supports such API response interceptions.
On the other hand, scenario testing fits better with real API data as data consistency is the key part.
- Interactive Testing → Mock Data
- Scenario Testing → Actual API Data
3rd Reason: Separate SSR and CSR pages
Secondly, interactive testing within a specific page can test SSR behaviors, while scenario testing across pages can test CSR behaviors. Developers cannot be ignorant of these differences, or runtime behaviors would fail in untested situations.
Decoupling into two types of testing enables us to run these tests independently, helps us develop e2e testing in a predictive manner, and analyze the cause of testing failures.
Testing Directory Structure
It is more maintainable to have the same folder path and file names in the in the testing folder as the routes/pages folder.
For instance, cypress/integrations/top.spec.js tests all interactive cases in the Top page.
And interactive testings are stored under the integrations folder (instead of interactive folder) because Cypress has this folder by default.
Here is a sample folder directory if you choose Cypress.
cypress
├ integrations
| ├ top.spec.js
| ├ search.spec.js
| ├ product.spec.js
| ├ cart.spec.js
| └ order.spec.js
|
├ scenarios
| ├ purchase
| ├ inquiry
| ├ cancellation
| └ content-reader
|
├ plugins
├ fixtures
└ others (downloads, screenshots, etc.)
That is it. I hope this tip will help you plan your e2e testing.
Thanks!
Top comments (1)