I'm always being pushed for feature development and then held to dates that don't give enough time for writing unit tests.

What practices can I use to be a better advocate for getting unit tests written?


5 Answers 5


10 Ways to be a test advocate

  1. Measure test coverage and make that coverage a visible KPI

  2. Talk about testing in details during backlog refinement for the each ticket

  3. Push for tests running in CI and require them to pass in order to merge code

  4. Don't give immediate time estimates. Promise them tomorrow. Wait to be asked again.

  5. Know and Use the 7 magic words for backlog refinement. How Are We Going To Test This ?

  6. If forced to give an estimate triple the development time to allow for also writing the unit tests

  7. Present topics such as the Agile Test Pyramid and How To Mock Our Data to the local community

  8. Make plans for unit, integrated and e2e tests that the feature should include during backlog refinement

  9. Make sure the product owner understand that application code requires unit tests as part of feature delivery

  10. Don't give out updates in stand-ups that indicate that the feature is "done" or "mostly done" when the tests aren't done

  • A lot of the things you mention will be the result of advocating for getting unit tests written, a manger reluctant to assign time for testing will net agree to a feature not being DONE due to lack of tests, or agree to assign time for tests
    – Rsf
    Commented Apr 28, 2023 at 11:56

What practices can I use to be a better advocate for getting unit tests written?


The tests are the drivers of the production code production. By definition, you will always have the tests that represent the specific version of your product.

And it tends to yield better internal and external quality in the product.

Writing tests after the fact are mostly a waste of time.

  1. They won't influence the design of your interfaces (which tend to be of lower quality);

  2. The tests coding is an additional step after you already have the production code that brings value to the users;

  3. The tests have the potential to be discarded on the next set of changes. Thus, they won't bring even regression detection benefits in this case.

  • TDD will be the result of advocate for getting unit tests written, a manger reluctant to assign time for testing will net agree to use TDD
    – Rsf
    Commented Apr 28, 2023 at 11:52
  • If the "manager" is the person responsible for the coding (i.e. an Eng. Lead) and he/she generally deny TDD, then this person is not doing a good job. If the "manager" is not the responsible for the coding (i.e. a Project/Product Manager), then this person have not the authority over the coding practices of the team (the people who are responsible for coding) - in this case, the team/eng. manager has to say "no". It's a similar situation as if the CEO of a construction company comes demanding the bridge engineers to work like that X or Y - the CEO needs to convince the engineers. Commented Apr 29, 2023 at 9:52
  • 1
    Who's reporting on time spent "writing tests" vs. "implementing" anyway? This is just doing the job: it's design, helping you think through the problem, supporting implementation and refactoring, and creating tests.
    – jonrsharpe
    Commented Apr 30, 2023 at 13:34
  • @JoãoFarias you are right in that there are incompetent managers at all levels, but that is not always solvable as the skip manager might be as incompetent and non techy...
    – Rsf
    Commented May 2, 2023 at 9:12

There are some partially good answers here, but I think that in summary the answer is simple- Data. Show bugs that could have been avoided, estimate the needed time for testing and show the ROI on it, bring research showing the benefits in testing and demonstrate how simple adding tests can be.


Make unit testing part of your development process like in TDD. Unit tests speed up your productivity because when you change/refactor code you don't need to test many things manually or deploy the whole app. That's, I assume, something you, as a developer, know. But it might happen that your manager is less technical and hence doesn't know. And doesn't have to. And, controversially, you don't have to tell him.

I like what Martin Fowler wrote about refactoring:

Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!

Subversive? I don't think so. Software developers are professionals. Our job is to build effective software as rapidly as we can. … A schedule-driven manager wants me to do things the fastest way I can; how I do it is my business. The fastest way is to refactor; therefore I refactor.

(Refactoring, 2nd Edition, p. 55)

I think the same applies to unit testing. Just replace "refactoring" with "unit testing" in the quote above.


If you, as the developer, are also responsible for your unit tests, the simple answer is: write the tests first, before your write the code!

Generally, I'd advise against the same person writing the code and then testing it, as they'll make the same assumptions in both phases, and potentially miss important edge cases.

But it seems a perverse feature of project managers (or their agile equivalents) that you'll always get some extra time to finish coding, but not to finish writing tests... so write the tests first, then get the xtra time to finish the code.

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.