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?
Give them training in writing good unit-tests and show them how they help with refactoring. Most developers I know love refactoring, writing tests soso, 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.
Write Unit tests!
Observe the testing quadrants!!
Follow the test pyramid!!!
Many companies state these objectives but fail to follow though 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 tests 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
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 lets 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:
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."
When you don't write tests you frequently develop compensating techniques:
Unfortunately all of the above are negative code quality factors. Unfortunately they are also self-reinforcing and often occur is 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?
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
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 changes 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.