Follow me on Twitter! @NoriSte
Built and maintained by our Steering Committee and Collaborators
(Work in progress)
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
(Work in progress, take a look at the sections draft file)
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
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
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
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
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
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
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
TL;DR: The UI communicates continuously with the back-end, and usually every communication is critical. A bad request or a bed 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
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.
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.
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!
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
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.
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 |
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.
A successfull PR gives you a 🌻, be the first to collect it.
🌻 Ferdinando Santacroce 🌻 Luca Piazzoni 🌻 Luca Previtali
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.