Developers don't write enough or good unit tests, how to address?

Question

Many developers still not seem to the the value and need for unit tests.

What might be are the reasons for this so we can address it?

Answer 1

Give them training in writing good unit-tests and show them how they help with refactoring. Most developers I know love refactoring, writing tests so so, but they love refactoring with confidence more.

Also, good tests lower debugging time, which is also something developers dislike. The Google internal Testings on the Toilet movement focuses on this with their moto: Debugging sucks, Testing rocks.

Answer 2

Ensure there is technical leadership for code quality !!!

I recently heard another version of this, i.e.

"Our developers don't want to write tests, how to persuade them?"
They literally say "everywhere I've worked we had a QA team that did that for us. it slows us down. I'm a developer, not a tester."

Answer...

When you don't write tests you frequently develop compensating techniques:

• Heros who are the only ones who can change some of the code
• Code that is hard to test on a DevOps pipeline
• Massive amounts of extensive manual testing
• Lots of comments, some of which are current
• Code you don't refactor in case you break it
• Code with poor or missing documentation
• Code that individuals, not teams 'own'
• Code that is not written to be testable
• Code with heavy dependencies
• Code that is highly coupled
• Code with a high bus factor

Unfortunately all of the above are negative code quality factors. Unfortunately, they are also self-reinforcing and often occur in certain industries. Banking is probably the most well-known example.

Perhaps worst of all, these factors and approaches have developed over time.
Pointing them out as negatives will likely infuriate and annoy the developers who have developed them.
How to convince them to change?

Start with Technical Leadership to promote good practices and approaches.

Make quality code and quality code practices (which will include automated tests) a key factor in the organization. Give it a place on the portfolio of what management measure and talk about and set goals for quality code.

Start developing a culture of developers who care about quality code and practices.

Also, a key thing is

Sell the benefits.

I used to write code without tests. But boy when it broke those were some very late nights. Tests are programmers bests friend cos they let you change code safely. Like without losing millions of dollars or without getting fired. They let you change and modify code safely knowing whether or not you broke the software. Once you get used to this you can't imagine developing software of any complexity that needs to be changed quickly (i.e. today's world) without automated tests.

Also, TDD and BDD depend on tests to drive the design.
When you don't have tests, you're winging it and creating a code monster.

Answer 3

Write Unit tests!
Observe the testing quadrants!!
Follow the test pyramid!!!

Many companies state these objectives but fail to follow through on making sure that the actual issues encountered writing unit tests are recognized and addressed. That's a lot more organizational support needed. If it is enforced with deadlines and number of test metrics it may not end well. The recent desire for KPIs and metrics everywhere can be dangerous if used bluntly here. Remember, past a certain point, more tests is WORSE not better because they will fail incorrectly and take maintenance.

I would consider starting with the following survey to unearth what the issue(s) are:

What gets in your way of writing unit tests while you work?

I would use multi-choice answers of

• I don’t know where to start
• I don’t have enough time generally
• The environment or database is unstable causing them to fail and not provide value
• When I am given a fixed deadline, sometimes there isn’t enough time for testing
• Production is broken and we don’t have time for unit tests right now
• I don’t have existing templates to base new code on
• I don’t know patterns and practices for writing unit tests
• I haven’t written unit tests before
• I don’t know how to do the mock and stub piece
• I don’t know when to use them and when not to
• I don’t understand how to make them part of a suite that others will run
• I don’t understand how to create and run certain tests when a real user id is needed

That is just a start. It is just an assessment of the current practices.
However, it will give you a good start on knowing where to work on improving quality and let's face it that is the first step in any such process - get the raw data so you know where the issues (are). Otherwise, you might work on fixing the wrong thing and not fixing the right thing!

In order to actually improve quality, you will need to find ways to promote each of these items. Some initial suggestions are:

• Improve developers' ability to state their need for time to work on tests. Constantly encourage assertiveness and mistakes
• Allocate time (weeks and months) to work on the environment. Not just 'Wednesday for a couple of hours'. Make sure that this time is included in any sort of estimates for the business.
• Educate management that fixed deadlines hinder quality. Work with them to find a way to limit scope instead of quality
• Do not make unit tests optional and nice to have if we have time. Make them as much a part of the development as the application code. This takes discipline.
• Ensure that all external dependencies (services, database, network, file system, etc.) use stubs and mocks. Do not make the use of mocking and stubbing in unit tests optional and a 'nice to have if we have time'. Make them as much a part of the development as the application code. This takes discipline.
• Provide education, training, Lunch and learns and other forums to encourage learning about Agile testing
• Solve 'user id' problems upfront instead of hiding a hack