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?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.Sign up to join this community
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.
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 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?
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 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.
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
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: