Over the years, I've been part of two types of teams; those that fully believe in testing and those that don't even want to hear about it. Let's explore some pros and cons that I've noticed.
Pros
1. Existing functionality
When deploying code, developers have confidence that they are not breaking any existing functionality that tests were written for. This saves a significant amount of the team's time and prevents client/user frustration.
2. Feature discovery
Tests help developers understand how a feature should work. This is useful both as a refresher and for new joiners.
3. Reduced manual testing
E2E tests simulate how real users navigate through an application. This increases confidence towards whether the application works as expected without having to manually test everything before every deployment.
4. Debugging
Whenever a test fails, the developer can start debugging the issue from the specified test file. It's more intuitive than guessing where the issue might be coming from.
5. Improved developer satisfaction
Overall, higher developer satisfaction can be expected with tests in place as they don't have to waste time working on bugs/regressions that could have been avoid with tests.
Cons
1. Slower development
It's time-consuming to write and maintain tests. Flaky tests often cause pipelines to fail and need to be fixed/removed.
2. Slower deployment
Tests delay deployment. It's an extra step in the pipeline.
3. MVPs & one-offs
Tests are not always viable for MVPs or one-off projects.
Conclusion
The pros definitely outweigh the cons. However, most of the drawbacks can be countered. Raise awareness to clients regarding the importance of tests to them. Start taking tests into account in estimates. On another note, one-off projects and MVPs probably don't need tests as they will probably be scrapped/rewritten at some point. In case the project lives longer, start adding tests as soon as the confidence level on the codebase starts falling.