UI Testing Best Practices (Work in progress)
Follow me on Twitter! @NoriSte
Built and maintained by our Steering Committee and Collaborators
Latest Best Practices and News
(Work in progress)
Welcome! 3 Things You Ought To Know First:
1. You are, in fact, reading dozens of the best UI testing articles - this repository is a summary and curation of the top-ranked content on UI testing best practices, as well as content written here by collaborators
2. It is the largest compilation, and it is growing every week - currently, more than XX best practices, style guides, and architectural tips are presented. New issues and pull requests are welcome to keep this live book updated. We'd love to see you contributing here, whether that is fixing code mistakes, helping with translations, or suggesting brilliant new ideas. See our writing guidelines here
3. Most best practices have additional info - most bullets include a 🔗Read More link that expands on the practice with code examples, quotes from selected blogs and more information
Table of Contents
(Work in progress, take a look at the sections draft file)
- Testing strategies (4)
- Generic Best Practices (3)
- Server Communication Testing (3)
- Beginners (1)
- Generic testing perks (1)
- Tools (1)
- Real Life Examples (!)
1. Testing strategies
1.1 Component tests vs (UI) Integration tests vs E2E tests
TL;DR: Identifying the test types is the starting point to understand and master all the UI testing strategies, the tools, and the pro/cons of them. UI integration tests are the most effective ones (you are going to love them), E2E tests give you the highest confidence, and Component tests allow you to test the units of the UI in isolation.
Otherwise: You end up writing a lot of E2E tests without leveraging other simpler kind of tests. E2E tests are the most confident type of tests but even the hardest, slowest and most brittle ones.
🔗 Read More: Component vs (UI) Integration vs E2E tests
1.2 In the beginning, avoid perfectionism
TL;DR: Software Testing is an amazing topic but a limited experience could make you fighting with a new enemy instead of relying on a new ally. Avoid, if you can, to test every complex user flows since the beginning of your UI testing journey. The simpler your first tests are, the sooner you get the advantages.
Otherwise: You create complex and hard to be debugged tests. This kind of tests slow down your work and do not have any kind of usefulness.
🔗 Read More: In the beginning, avoid perfectionism
1.3 Choose a reference browser
TL;DR: Cross-browser testing is way overrated. It's an important topic and it's the first thing you can think while starting evaluating the right testing tool. Don't worry: start by splitting functional testing from visual testing, that's the first step to correctly evaluate the need for cross-browser support (and to choose the right testing tool, too). Visual testing can be integrated into every testing tool, thank services like Applitools and Percy.
Otherwise: You could choose the wrong testing tool based on the cross-browser support.
🔗 Read More: Choose a reference browser
1.4 Found a bug? Write the test, then fix it
TL;DR: A test is a good ally when you need to be sure that you are able to systematically reproducing a bug. A test allows you to speed up the fixing flow and to be 100% confident that the same bug is caught forever.
Otherwise: You could not identify correctly the bug and you can not be sure that the bug will not present again in the future.
🔗 Read More: Found a bug? Write the test, then fix it
2. Generic Best Practices
2.1 Await, don't sleep
TL;DR: When testing your UI, you define a sort of key points the app must pass through. Reaching these key points is an asynchronous process because, almost 100% of the times, your UI does not update synchronously. Those key points are called deterministic events, as known as something that you know that must happen. You need to wait for these events to make your tests robust.
Otherwise: Sleeping the tests make your tests slow and brittle, it's one of the most common and biggest errors in UI testing.
🔗 Read More: Await, don't sleep
2.2 Name your test files wisely
TL;DR: Lot of times you need to launch just a type of tests and it's super easy if you follow a common pattern while naming your testing files.
Otherwise: You need to launch a long test suite just to have some of them run.
🔗 Read More: Name the test files wisely
2.3 Use your testing tool as your primary development tool
TL;DR: Leveraging your testing tool to avoid manual tests is one of the biggest improvements you could do to speed up your working flow. Testing tools are faster than you and the most modern ones include some UI utilities that make easy to use them as a development tool.
Otherwise: You code the app the old way, losing a lot of time interacting manually with the UI itself.
🔗 Read More: Use your testing tool as your primary development tool
3. Server Communication Testing
3.1 Test the request and response payloads
TL;DR: The UI communicates continuously with the back-end, and usually every communication is critical. A bad request or a bad response could cause inconsistent data and inconsistent UI state. Remember that all the business is built around data and the user experience is scratched by every single UI failure. So, every single XHR request must be checked carefully. XHR request checks make your test more robust too, correct XHR management and testing are one of the most important aspects of a UI test.
Otherwise: You could miss some relevant communication inconsistencies and when you need to debug them, you are going to waste a lot of time because the test will not drive you directly to the issue.
🔗 Read More: Test the request and response payloads
3.2 Test the server schema
TL;DR: A lot of times, the front-end application breaks because of a change in the back-end. Ask your back-end colleagues to allow you to export every schema that describes the back-end entities and the communication with the front-end. Some examples could be the GraphQL schema, the ElasticSearch mapping, a Postman configuration, etc. more in general, everything that can warn you that something changed in the back-end. Every back-end change could impact the front-end and you must discover it as soonest as possible. You can keep the schema checked with a simple snapshot test.
Otherwise: You could miss some back-end change and your front-end application could break inadvertently.
3.3 Monitoring tests
TL;DR: The more the test suites are launched periodically, the more confident you are that everything works as expected. UI tests should be based on the user perspective but there are a lot of small tests that could give you a lot of immediate feedback without debugging the expected user flows. Monitoring small and taken-for-granted tech details helps you preventing bigger test failures.
Otherwise: You mix tech-details tests with the user-oriented ones.
4. Beginners
4.1 Approach the testing pyramid from the top!
TL;DR: Approaching the testing world could be inefficient and not satisfactory. You start writing some unit tests but you are left with a lot of doubts. UI Testing allows you to start with a high confidence since the very first day.
Otherwise: The wrong approach could condition the way you think about testing and could leave you with the false idea of testing the right way when the truth is you're testing nothing.
🔗 Read More: Approach the testing pyramid from the top!
5. Generic testing perks
5.1 Software tests as a documentation tool
TL;DR: Tests are a good way to have a concise, code-coupled, and updated documentation. Good storytelling test descriptions could make the comprehension of a codebase or a new project very simple.
Otherwise: You rely on the code documentation or, worse, on the readability of the code to comprehend that the code does.
🔗 Read More: Software tests as a documentation tool
6. Tools
6.1 Some UI testing problems and the Cypress way
TL;DR: Why is testing a web application so hard? Why generic browser automation tools do not fit well the UI/E2E testing needs? Why does Cypress outstand?
Otherwise: A generic features comparison is not enough to understand what are the main UI Testing pains and how Cypress removes them.
🔗 Read More: Some UI testing problems and the Cypress way
7. Real Life Examples
Siemens - Test the front-end with the integration tests, the back-end with the E2E ones - in reference to Component vs Integration vs E2e Testing
TL;DR: UI tests with a stubbed server are reliable and faster compared to full E2E tests. Full E2E tests are not always necessary to ensure front-end quality. We can instead have high confidence in front-end quality by using lower-cost UI integration tests and saving higher cost E2E tests for the back-end.
Otherwise: You waste time and resources with slow and brittle E2E tests while you can get a lot of confidence with a lot of UI integrations tests.
🔗 Read More: Test the front-end with the integration tests, the back-end with the E2E ones
6. Advanced
6.1 Test States
TL;DR: Tests should be repeatable, modular and should handle their own state setup. UI Tests should not be repeated in order to achieve state for another test.
6.2 Test Flake
TL;DR: Tests must produce consistent results every time. Repeatable pipeline execution results are the quorum. If a test cannot produce reliable results, it reduces confidence in the tests and requires maintenance which reduces all value. In these cases it is best to manually test the functionality.
Steering Committee
Meet the steering committee members - the people who work together to provide guidance and future direction to the project.
A positive-minded front-end developer and Cypress Ambassador. He's a passion for good UIs, automation, testing and teaching. He's developed every kind of interface: webapps, mobile apps, smartTV apps and games.
Collaborators
Thank you to all our collaborators! 🙏
Our collaborators are members who are contributing to the repository on a reguar basis, through suggesting new best practices, triaging issues, reviewing pull requests and more. If you are interested in helping us guide thousands of people to craft better UI tests, please read our contributor guidelines 🎉
 |
 |
|---|---|
| Anoop Kumar Gupta | Murat Ozcan  |
Thank You Notes
We appreciate any contribution, from a single word fix to a new best practice. Below is a list of everyone who contributed to this project. A 🌻 marks a successful pull request and a ⭐ marks an approved new best practice.
Flowers
A successfull PR gives you a 🌻, be the first to collect it.
🌻 Ferdinando Santacroce 🌻 Luca Piazzoni 🌻 Luca Previtali
Stars
An approved new best practice Be the first to collect a ⭐, contribute to this repository 😁
This repository is inspired to the nodebestpractices one, thank you Yoni and the whole steering team to keep it updated and to allow the creation of this repository.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent