Isn’t it a pain when you have worked on a feature, tested it yourself thousands of times while developing it, and then, after deploying it to test or to go into production, you get a frustrating notification that it is not working as it should? A comment within a ticket, a message by a tester or the product owner, “Hello <developer_name>!! This feature you made is broken!” Well, did you know you can potentially prevent this from happening? End-to-end testing is the answer.
You might we be wondering, what is end-to-end testing (e2e)? End-to-end testing refers to a software testing method that involves testing an application’s workflow from beginning to end. This method aims to replicate real user scenarios to validate the system core integration and data integrity.
Cypress in action
The framework I would recommend using is Cypress. For the last two months, I have been working with Cypress on a project and based on my recent experience with the framework, I would strongly recommend it. The automated end-to-end tests I have written using Cypress, have given my direct team and me more reassurance that at least the essential core features will still be working after changes have been made on top of the features’ work.
https://www.webdevstudios.com/wp-content/uploads/2018/10/cypress.gif
Some of the features from Cypress that I found quite useful are the following:
It handles the browser as a real user would:
- Using their API in JavaScript, I can write down what a user would do. Such as clicking on a button, and simulate an entire flow for how a user would use and experience my application. How great!
It has a test runner UI for developers:
- Using the test runner UI, I can run the Cypress runner on another screen to track my test progress while writing the test inside my e2e. This means you get immediate feedback showing how the test is failing or succeeding, so you can progress faster when writing an e2e test.
It has time travel de-bugging capabilities:
- In each step of the e2e test runner, you can go back and see the exact state of a test during the specific step you selected at the time. This means Console.log() de-bugging will be used less in the de-bugging experience.
It is super easy to set up and has great documentation:
- It was surprising to see how easy it was to set up Cypress. It only took one install command and straightforward documentation, which helped me quickly dive into writing my e2e test.
It records your tests and saves them in the cloud:
- You have the option to record your e2e tests. This way, you can investigate from the user point-of-view where the error in your test suite might have occurred, alongside the steps of your test.
The learning curve is minimal, hence you can use your existing JavaScript knowledge:
- Even the most basic JavaScript knowledge should help write your first e2e test. As I mentioned before, a test shows step-by-step what a user would do to achieve the expected result of using your application.
Key experiences writing e2e tests
I would like to share with you some of the key experiences of writing e2e tests that you might find useful:
Write your tests from the point-of-view of the user:
- When you are writing an e2e test, the approach to writing this test should be generally straight forward. Of course, keep in mind what is required and requested in your situation. Try to imagine going through the flow of what a user sees on the screen, what they might do, and what they might click on. Try to imagine yourself as the user of the application itself. What does the user want to accomplish and how? So let’s use the login feature as an example. If the user already knows their login credentials, what would they do? Fill in the credentials, perhaps insert a wrong input so an error message would be displayed, etc.
Try to cover the edge cases as well:
- What you might forget to write is the edge cases for your feature. This means a situation that rarely occurs but can occur. This means for me to try to incorporate your developer’s mindset into thinking further than only the ‘happy’ case where your feature is working as planned and expected. What should happen when the goal cannot be accomplished? What is the desired result then?
End-to-end testing should cover business rules based on the user’s requirements:
- I think this an important point to cover. These rules determine how it responds to most of the cases or state of your application or feature.
End-to-end testing gives renewed confidence that the frontend is still intact and functional:
- When I wrote about the features I have been working on, I had the confidence that they were working and intact as soon as fellow developers and teammates reviewed my work. However, as time goes by, features that might not be used by real users or if they have not been tested for an extended amount of time can give you less confidence.
- By writing the e2e tests that will be automated, you will be getting your e2e test runs in your CI/CD environment, a stable level of confidence that these functionalities will continue to work. Thus, on a basic level confirming that the end-users can still utilize the core features.
Conclusion
Before you start writing an end-to-end test, you might think that it is cumbersome or could slow down your development process. Eventually, the more experience you gain writing e2e tests and seeing the results of the tests that you write, you will gain more confidence in your feature and project as a whole. It is unnecessary for you to reference back to your work all the time, which saves you, your team, and your client a significant headache from regression testing. At least test the features most important for your project, which can be frequently simulated in the tests to make sure that they stand intact. After sharing my experience with Cypress and end-to-end testing, if you decide to try it for yourself, this should give you and your team more confidence in your application.
Sources:
- Author’s experience: Laurent Kleering van Beerenbergh
- What is end-to-end testing: https://www.browserstack.com/guide/end-to-end-testing
- http://brettcassette.com
- http://agileinaflash.blogspot.com/2009/02/first.html
- https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
- https://dzone.com/articles/what-is-end-to-end-testing-1
- https://www.linkedin.com/pulse/end-testing-aditi-mulay/
- https://cypress.io
