I’m a part of a large software project which is supposed to use TDD. There are maybe 90 devs across the world. Upon review of tests for software components, I determined that a significant number of tests are meaningless. They do something along the lines of :

  • Set true value on mock object, and check if it is true
  • Set up mock object, expect some behavior to NOT happen, then call some unrelated method. Of course the default value of the test variable remains false - the test did not touch it
  • Test description conflicts with the actual actions of test logic ( description says “disabled”, but the test logic passes “enabled”)

On paper, it seems like there are integration tests and unit tests. In reality, quite a lot of them are blatantly fake. Due to the large team size, I expect people would keep writing such garbage tests.

How do I deal with low quality unit tests? What can I do advocate for culture change? How can I help enforce that junior devs don’t write garbage tests for critical system components?

  • 2
    I guess you have figured this out already, but I'm still going to say this: they are not using TDD. They are just writing arbitrary tests. They probably don't know how to implement TDD properly. Sep 24, 2018 at 3:54

5 Answers 5


Recognize that there is a large organizational problem.
Management have to change and give true leadership

Talk to management about:

  • quality
  • developer morale
  • developer training & education
  • The risk of not having quality tests
  • senior developers leading by example
  • the affect on revenue (bugs and rework)
  • the effect on customers (bug and rework)
  • the affect on agility to respond to the market
  • the effect on the ability to deliver fast to compete
  • senior developers constantly giving lunch and learns and training

If you do not find a receptive audience please seek a job at another company.


I believe that the strongest instrument for filtering such a-low-quality tests is a code review. You can power-up your code review with mutational testing techniques which will help you to detect the tests which probably do not introduce any value to the overall project scope.

Here is the example of mutational testing framework where you can pick some concepts and probably look for alternatives for your programming language.


Some things which seem to have worked for the teams I've worked in:

  1. Get permission, record what you do of the below, then present the final result to your colleagues to get them interested in developing better tests. Make sure you don't end up insulting anyone's talent - we all have to start somewhere! It might be tempting for illustration purposes, but don't even include the original code in your presentation.
  2. In case of negative tests, either find a way to test them positively or remove them.
  3. Write tests which actually correspond to the documentation. If you find any bugs in the production code along the way that's a bonus you can add to the presentation.
  4. Record any missing tests, and write them if you have the time.
  5. Record anonymous metrics such as how much you reduced cyclomatic complexity, SLOCs, and numbers of various types of test bugs you fixed.

How to improve Testing Culture:

  • Mob sessions to help the devs start to go through worked examples and see what good tests look like vs. Bad so they can learn through examples.
  • Code reviews, to go through change sets ans see what code has been commited and feedback to thr dev about the test added.

  • Start hosting regular "lunch and learn" or "tech develops meeting" with a focus on every team in rotation hosting one a week on practices and things they've been working on. You can start with Improving functional testing.

  • Appoint test champions, who will evangelise the correct way to write unit tests. They can help propogate proper testing. You can convince management as, it will also help define the champions yearly objectives.

  • Start a code craftsmanship course in your organisation, this will help everyone understand what good tests look like with the theory to support it.


A test at it's best is just a Boolean question to the SUT.

In a similar situation, I would try to map each found defect( from defect database) back to these test cases. And will try to find out (as a team) did we ask the right questions and particularly what questions are missed out and why?

If most of the tests are meaningless, then many defects will not be mapped to any of these test cases.

This exercise itself will suggest to the team about the effectiveness of the tests and right course of action in the future.

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.