Recently I have begun building out Unit Testing for my dev team during down time in an attempt to implement the Test Pyramid. My Dev Managers seem rather excited about it and on-board with the idea.

I was wondering if anyone else has implemented and enforced the test pyramid guidelines and if so, how was it done. In particular, how can I convince the Developers to maintain and implement Unit/Integration Tests into their work?


2 Answers 2


I am definitely using the test pyramid as one of my 'guidance' tools.
I frequently combine it with the 4 Agile Testing quadrants in talks and presentations.

                               enter image description here

enter image description here

As Niels says this is more of a guideline than a specific implementation

I introduce and encourage it by:

  • introducing it when onboarding both development and QE engineers about our quality practices
  • revisiting it during book review as we go through Agile Testing by Lisa Crispin and Janet Gregory
  • using it to guide our testing efforts when looking at tickets during sprint review and pointing

I talk about the several companies that I've worked at that had thousands of unit tests and then a few dozen UI feature tests

I refer to it when having discussion about mocking and stubbing so folks can see when db access is actually tested in higher level UI feature specs.

I think you can convince the Developers to maintain and implement Unit/Integration Tests into their work by:

  • making sure folks know how automated testing adds value by letting you know if you break stuff
  • making sure that database and other dependencies are stubbed out for unit tests so that they run quickly - many tests per second, not many seconds per test
  • looking at recent bugs that could have been prevented if tests were in place
  • talking about the feeling and stress of changing systems without unit tests vs. having tests to safeguard against unexpected changes
  • emphasizing that tests suites should be less than about 10 minutes to run the full suite

The Test Pyramid is not something you implement, but more a guideline showing how to spread the testing efforts. Also it should be a guide to prevent an Agile anti-pattern "the ice-cream test cone".

A possible way to enforce creating automated tests is to set a test-coverage standard. You can use a code-analyses tool (e.g. SonarQube) to monitor trends on this. These tools can even deny pull-requests or send alerts.

enter image description here

You can start with a minimal test-coverage of let's say 35%, this forces everyone to write at least one test for the code. Later you can say new code must not trends it below 35%. Some months in the future you can upgrade the percentage to 65% or higher. Xp teams have a target of 85 up-to 100% coverage. For legacy code-bases this is a dream you might achieve, set realistic targets. Also keep in mind testing is the goal, not coverage.

Focus on trends not the exact numbers. New code should not bring the current code-coverage statistic down, the number should always go up.

To train & convince developers in automated testing I have started doing Coding-Dojo's with my current teams. In the dojo sessions we use TDD techniques to get the developers familiar with unit-testing and writing good tests. Each iteration we do one 1,5 hour session. In parallel we watch & discuss an UncleBob's CleanCode video each iteration, some also focus on TTD and code test-ability. This is time demanding, but most developers do not have the free time to learn outside of work. I really think developers should grow each iteration and learn how to make testable and maintainable code.

Other sources:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.