How did you convince your manager to let you unit test?
By "use", I mean being allowed to develop, check-in to source control and maintain the unit tests over time, etc.
Typical management objections are:
Do you know other objections? What were your answers?
Thanks in advance!
I ran into this problem recently when a customer was on board with our methodology, but higher management got wind that the developers were spending their time testing rather than developing and were concerned about this - after all, they had QA people to do the testing!
This is how I dealt with the situation (read my old blog post for more details). I compared our estimated hours against actual hours for the project and then compared our defect rate against other teams' defect rate. In our case these numbers compared favourably and there were no more concerns.
My conclusion based on this experience is:
...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.
On other projects, we've worked alongside customer developers who didn't create unit tests or do TDD and we've had to maintain tests that they break. However, it becomes very easy to sell the TDD approach to those customer developers when you can tell them what they've broken in the code before they know!
So in your case, I would do it by stealth if necessary (perhaps there is a small area of the code that you can start to test that changes often or that you are responsible for), but keep track of your numbers - what is the effort for creating your tests? What is the defect rate? How does this compare with other projects / team members?
In my opinion, no-one should need to ask permission or apologize for wanting to do their job properly and any professional developer should be attempting to test their code with automated tests wherever it's possible and practical. Hopefully it's both of these things in your case. Good luck!
Writing automated tests takes time. Once. Running automated tests takes zero time, because you can do something else while they're running.
Example: Manually testing feature X takes 30 minutes. Writing an automated test for it would take 1 hour. Even if we have no bugs, we will have to test feature X ten times during the course of the project as its dependent layers and components are modified. So automating the test of feature X will save us 4 hours over the life of the project.
In reality, it's when you have a bug that automated tests really pay off - First, they find bugs early and cheaply, which saves time and embarrassment. Second, if you have a difficult bug and go through many cycles of code-build-test to figure it out, the time saved over manual testing adds up extraordinarily fast.
Businesses understand saving time and money. That's how to sell it.
If you've confronted them already, and they're not ok with it, but you don't feel comfortable writing code without them... then don't ask again. Just write them and don't check them in.
Management isn't going to count lines of code, but they will see that all of your checkins have higher pass rates from QA (or customers) and they'll eventually ask why... then you can be all like "BAM! TDD!"
You're not messing with the project, process or source... so I don't see a negative reason. Honestly, I don't see a reason why it's any different time-wise than running all of your manual run+input+check results tests.
1) The customer didn't pay for unit tests
The customer (thought they) paid for a working solution. Depending on the contractuals fixing defects may actually be profitable to your company. If there's sufficient lock in. So going back to paying for a working solution. TDD should aid that goal.
2) The project does not allow time for TDD
TDD doesn't take longer. It should reduce the amount of extraneous or superfluous code and focus the code base on what makes the tests pass. All the tests passing, subject to test quality and appropriateness, means the code is done.
3) Technical debt? What technical debt?
I get the impression that you might be arguing for retrospectively adding tests to existing code. This is a nightmare sell at the best of times and doesn't bring the benefits that you might expect. However, adding tests as you fix bugs should be acceptable and help in the long run.
I don't recommend writing the tests anyway as Snorfus has suggested. It sounds nice in theory, but unit tests can and do change over time. As requirements change, new features are added the unit tests need to be updated. If you're working as part of a team your unit tests will become out dated as others add features/fixes.
I'm addressing the specific points you mentioned rather than raising new ones because there's leeway there to make progress or understand why it's being cockblocked.
For every customer facing production issues,
Write a Unit test and send an email to the manager saying that You have added a Unit test to cover the scenario.
And tell him that This issue will not happen again in production because our unit test is running nightly and we will come to know before the code goes to production by watching this unit test failure.
Tell him that if we already had this Unit test in place before the code went to production, this production issue would never have happened.
Do this consistently and persistently and soon he will be convinced. Managers do not like the customer facing production issues and he will buy into the Unit testing idea. Good luck.
