Unit-testing, oftentimes, is thought of as a burden and not exciting at all - more code to write, configure and maintain which requires time which results into delays in delivering features or fixes.

What may motivate or convince developers to write unit tests?

I'd like the question to be generic, but, if some context needed, here is our story:

We have several JS UI developers that don't write unit tests at all - we try to compensate by extra manual and automated end-to-end UI testing (we basically have this pyramid flipped upside-down). Their reasoning is that we have a lot of immediate customer demands which we need to fulfill - cannot afford extra time for tests.

  • This question might be better suites and already asked on softwareengineering.stackexchange.com . Maybe you can change the question to "how can TESTERS motivate" that would make it more suited for this SE. Jun 30, 2017 at 18:15
  • @NielsvanReijmersdal good point, adjusted the title, thanks!
    – alecxe
    Jun 30, 2017 at 18:20
  • 2
    I imagine many cases of missing unit tests are not due to lack of motivation from the developers, but rather due to unrealistic deadlines and management focusing more on releasing features than on the quality of the code base. Any developer who has ever refactored a code base with good unit test coverage should already know the value of unit tests, and if they expect to keep working on the code base that should motivate them to write unit tests.
    – kasperd
    Jul 1, 2017 at 17:03
  • @kasperd good point, I think that at least partially applies to our case - it might be that we are understaffed at this point. There though is a motivation issue at least to some degree. Thanks.
    – alecxe
    Jul 1, 2017 at 17:47
  • 1
    @kasperd +1 as it is indeed often a management and/or cultural issue. At our company, tests are an integral part of our DoD and there's a timebox for test automation in each sprint. This really helps to have an healthy balance between features and tests.
    – beatngu13
    Jul 11, 2017 at 13:44

6 Answers 6


It starts with explaining developers to take their discipline serious. They should follow the programmers oath.

I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.

I like how UncleBob compares developing software to double-book-keeping in accounting and disciplines like hand-washing in medicine. Things that for decades where frowned upon in their respected fields. Now these practises are enforced by law.

Unit-tests are not for the users, not for the testers, not for managers, not for build-systems, but for developers! As they remove the fear of change. Removing the fear of change leads to be able to practise refactoring. Refactoring is the number one skill in keeping software maintainable and extendable. This is why every developer should want their coworkers to write good decoupled code that is well unit-tested.

Teach the four TDD skills with doing coding dojo's:

  • Driving development with test cases
  • Designing test cases
  • Refactoring safely
  • Designing clean code

Codo dojo's are pre-made exercises that focus on training these skills and are very fun todo in a group. Unit-tests without good refactoring skills is not fun. Read this article about #NoTDD which explains not TDD, but refactoring is key in this practise.

Watch the Clean Code fundamentals with your development team. It contains two great episodes on TDD and he keeps showing why unit-tests are key in Agile software development. We watch one episode each iterations and the developers love it.

Unit-testing, oftentimes, is thought of as a burden and not exciting at all

Testing at the end is boring, writing unit-tests after the code is boring. Stuff at the end of the process is something you skip under pressure. Stuff at the end of the process is therefor often optional. Testing is NOT optional. That why you should do it before you write any code. :)

I would like to say make, but I say motivate your developers to read the CleanCode book. If that does not convince someone to write unit-tests than nothing will.

  • +1 If you ever refactor without tests compared to with tests you'll likely have 'felt' this difference. I certainly have. Jul 1, 2017 at 9:44
  • If you know a shop where testers would be "explaining developers to take their discipline serious" please let me know. developers should get that guidance and direction from their managers. You can support those efforts but should not be the initiator. Jul 5, 2017 at 18:07
  • Managers have no idea, they focus on speed and velocity often, not quality. Testers should step-up and take responsibility for quality and make sure a product does not resist change. "The secondary value of software is its behavior. The ability of software to tolerate and facilitate such ongoing change is the primary value of software. The primary value of software is that it’s soft." -- UncleBob seasidetesting.com/2013/03/12/… Jul 5, 2017 at 20:45
  • Supporting those efforts in my book means making everyone aware. After everyone is aware you can support them. Quality is a whole team approach, not just the managers, not just the developers, not just the testers. It has nothing todo with the shop, it has everything todo with how proactive your testers are. Thinking your second rank means you are second rank. Coming from reactive (it is not my job) thinking to taking control of your products quality is not an easy task, but really give it try and create the shop you want to work in don't think you will find the perfect shop somewhere else. Jul 5, 2017 at 20:51
  • @MichaelDurrant Sadly I have worked for several and it has been quite an experience...I ended up automating processes to decrease test burden and then getting more test time which swamped the dev team with bugs that weren't found due to continual testing cuts before, but sadly management decided they needed dev to just work 50+ hour weeks instead of deciding they needed to change the process to produce better quality code. They are certainly out there...
    – mutt
    Jul 8, 2017 at 7:33

Unit test are far superior in detecting root cause of the bug, compared to e2e tests. Maybe I am lucky, but our developers are religious about adding unit tests - because they experienced that it helps them to detect errors sooner, and allow for refactoring.

When e2e test reports a problem, you have to investigate what went wrong. Unit test tells you exactly what went wrong, so even investigation part is substantially shortened.

It is a cultural problem and management problem.

Did you had an issue recently where functionality regressed? When you were doing post-mortem analysis, obvious suggestion would be to add automated test to check for the condition.

Automated unit test are the first level of defense. In opinion of many test gurus, you would not even consider starting writing e2e test unless you have comprehensive unit tests.


Specifically, how can testers motive developers ?

This is actually a hard question. Especially the motivation piece. Some suggestions for that specific part:

  • Be critical of code but not people who write it
  • Be an easy-going fun flexible person to work with
  • Develop good relations with programming managers
  • Be enthusiastic about testing and how wonderful it can be
  • Give lunch and learns on testing, TDD, BDD and their benefits
  • Work with management on what criteria people are reviewed on
  • Participate in application code reviews so help is a two-way street

More generally:

Teach TDD

Not the "code should be covered by tests at some point... version" but the

  • Write a failing test
  • Write the code to make it pass


Also three keys thing: culture, refactoring and rewards($)

Have lots of ongoing conversations about tests, unit tests, which tests to write, test good practices, when to write functional ui tests, how to manage overlap of tests, etc. Make testing a frequent topic of conversation in the group.

Refactoring: As Niels pointed out, being able to refactor 'in safety' is a wonderful and amazing thing. It is part of culture but well worth calling out on its own! I recently wrote a bunch of bash scripts and ended up writing a small test framework just so I could refactor them. The ability to do the refactoring and run those tests as I was doing it was invaluable. Likewise the thought of changing them (whether refactoring, new features or bugs) was very scary. I guess I've bought into testing :)

Make sure that tests are part of developer employee evaluation and salary increases.

If you have old / legacy code*1 measure what is currently tested*2 and make a project to fill in the holes / untested application code. If code is older technology without tests, consider wrapping in newer tests.

*1 The best definition of legacy code I've seen is "the code you have in production today"

*2 Use a code coverage measure tool such as codecov, code climate, etc.

  • 1
    I would say teach refactoring and the developers will start valuing TDD, unit-tests and test-coverage a lot more. It is not about the tests, its about being able to change your code (and that of others) without fear. Resulting in code that is readable, maintainable, testable and extendable. Jun 30, 2017 at 18:28
  • Yes! Great point and I added it. Jul 1, 2017 at 12:45

Unit tests are better at isolating root causes of failures (as Peter Masiar pointed out in his answer). They are also more reliable and faster comparing to end-to-end tests. Mike Waker from Google explained that with lots of examples in "Just Say No to More End-to-End Tests". There is also a lot of industry research going on how hard (and thus expensinve) is to maintain end-to-end stable. See for instance "Winning with Flaky Test Automation" by Wayne Matthias Roseberry from Microsoft.

We have noted similar problems in our team. Similarly too you, we had far too many end-to-end tests in some areas comparing to unit and component tests. At some point we had a policy to close user stories only when 100% percent of end-to-end tests were passing, but since the end-to-end tests were quite unstable, we had a long queue of stories waiting for green tests. This was driving devs nuts and they have decided to help us move part of end-to-end tests to unit/component-level tests. That was only part of the solution to handle unstable tests but fixed the problem in two ways. First, technically it limited the number of unstable tests. Secondly, devs got more involved in testing and we got more involved in unit/component-level tests.


I use 2 approaches to motivate developers to write unit tests:

The best developers, those that are recognized highly, solve the hardest technical problems in a way that just works. Their solutions are high quality and bullet proof. The developers that reach the peak are those that also invest a lot of time in testing their own code to remove the bullets. Meeting a schedule might be recognized by the project manager as a good thing, but consistently delivering great software with high quality will be noticed by the senior leaders.

Second, explain how unit tests fit into the overall testing scheme. UI and API tests generally test happy path, or faults that can be injected via the data used. Its difficult/impossible to reach code that is in place to handle errors/exceptions. However, unit tests have full control over the mocked environment. With unit tests, its possible to simulate a slow network; its possible to test what happens when a dependent object is null.

Another benefit of unit tests, the business logic of your app can be tested very quickly, comprehensively, and with few false positives. Often, depending on UI driven tests to verify "the math" will result in many false errors (flaky tests).


What may motivate or convince developers to write unit tests?

  • Ideally, the most convincing evidence is perhaps a statistical comparison; if you could present a comparison between two similar projects, one with unit tests while another one without unit tests; despite requiring more time and effort to develop unit tests at the beginning, the project with unit tests should cost much fewer resources to maintain in the long term and hence having a higher business value.
  • But I guess everyone knows this in theory; the practical way to motivate developers to write unit tests is to educate the management that unit tests are needed sooner rather than later.
  • In practice, I doubt someone would be able to sweet-talk developers into writing test cases as ignoring sweet-talking carries no consequences. The only way to motivate or convince developers is to apply managerial pressure. Instead of sweet-talking to them, a manager will create tasks for unit tests; ignoring tasks carries real career risks.
  • As a tester, if it is allowed, please consider going and talking to developers' manager, and try to convince him/her that unit tests are mandatory; only then, writing unit test can be reinforced effectively.
  • 1
    Managers who force people to write unit-tests argh! really? You know how tests look like made by people who where forced to write tests? Watch this video TDD that’s not what we meant, as it has some good example tests that horrify me at night. vimeo.com/83960706 Jun 30, 2017 at 18:23
  • @NielsvanReijmersdal, I think you are picking on the word "force".
    – Yu Zhang
    Jun 30, 2017 at 18:26
  • 1
    "The only way to motivate or convince developers is to apply managerial pressure" I pick on this. It is wrong, its not of this age, it results in the wrong motivation. But maybe I am biased as I live in a culture with nearly no hierarchy and a lot of self-organisation. But those words hurts me as they do not fit my paradigms of this world. I can understand yours, but I do not think we should advocate them on a public website like this. Sorry. Jun 30, 2017 at 18:34
  • 1
    @NielsvanReijmersdal - please calm down. Yu Zhang, you missed a crucial clause in the statement "The only way to motivate or convince developers" - managerial pressure is the only way to motivate developers who have not learned the benefits of well-written unit tests. Niels works with developers who do know the benefits of well-written unit tests, so of course he finds a blanket statement offensive.
    – Kate Paulk
    Jun 30, 2017 at 19:25
  • 1
    We're all quality friends @YuZhang, KatePaulk and Niels :) I think if the phrase was 'A good way to motivate or convince developers is a management structure that focuses on testing, with rewards for the highest achievers' it might work better for everyone :) Jul 1, 2017 at 9:41

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.