<aside> 💡 Hola friends! We recently created a Discord for Software Automation where we discuss these kinds of topics on a bi-weekly basis.

Responses range from people with 0 to 30+ YOE in the industry and wanted to share this with the community!

</aside>

Abstract Summary:

This discussion explores various perspectives on software testing strategies, primarily focusing on the Testing Pyramid model and its alternatives. Contributors, ranging from experienced developers to QA professionals, share their views on the effectiveness and practical application of different testing approaches. The conversation covers topics such as the balance between unit, integration, and end-to-end tests, the challenges of implementing these strategies in real-world scenarios, and the evolving nature of testing methodologies in response to changing development practices and project requirements.

Key points of discussion include:

1. The validity and limitations of the Testing Pyramid model
2. Alternative models like the Testing Diamond and Testing Trophy
3. The impact of development methodologies (e.g., Agile) on testing practices
4. The importance of context-specific testing strategies
5. Challenges in maintaining and scaling different types of tests
6. The role of automation in testing
7. The relationship between testing strategies and code quality

<aside> 💡 Below are gathered discussions from the Discord as well as /r/softwaretesting, /r/programming, and /r/qualityassurance. Enjoy!

</aside>

Stefan Ayala (/u/basecase_) shares:

IMO The Testing Pyramid is a decent guideline overall and I’ve had success following it majority of my career, but in the last few years I have leaned more towards a Testing Diamond these days where I have most emphasis on my Integration tests and End-to-End /Unit tests are not the majority.

My reasoning behind putting more emphasis on Integration versus Unit is that many things start being conflated with Unit tests that IMO aren’t truly Unit tests and Integration tests seem to give the best bang for their buck if tooling is in place to support them.

Unit tests can be more difficult to write for developers especially if the code is a mess and isolating your System Under Test becomes a nightmare of Stubs/Mocks/Doubles/Fakes/Illuminati to test one function and may require refactoring.

Not to mention the more one starts mocking things, you might accidentally bypass an important System Under Test without knowing it.