How can testers motivate developers to write unit tests?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

version.

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

Culture:
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 :)

Reward($):
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.

Answer 4

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.

Answer 5

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).

Answer 6

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.