Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. The customer didn't pay for unit tests
  2. The project does not allow time for unit testing
  3. Technical debt? What technical debt?

Do you know other objections? What were your answers?

Thanks in advance!

share|improve this question
3  
There's a whole chapter in artofunittesting.com about this very topic. –  StuperUser Apr 4 '11 at 17:48
2  
Don't mix tests and TDD, PLEASE! It makes people think that they don't need tests unless they do TDD! –  Pavel Shved Apr 4 '11 at 19:18
1  
People who need convincing are beyond convincing. Consider your scenario a lost cause. –  Mark Canlas Apr 4 '11 at 22:24
    
@Pavel, at first I thought you were nitpicking, but you are right. I want to have the "permission" to unit test, period. TDD is my own thing. –  louisgab Apr 5 '11 at 14:56
3  
why do you feel the need to get permission to verify your code works as expected? –  Jaap May 20 '11 at 16:56
show 2 more comments

5 Answers

up vote 14 down vote accepted

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! I blogged about how I dealt with it here:

http://www.ext-it.com/2011/blog/show-them-the-numbers.html

To summarize, 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!

share|improve this answer
    
Thanks for the answer, and for the article link! –  louisgab Apr 5 '11 at 15:40
add comment

Show the ROI

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.

share|improve this answer
1  
Also once the application is deployed and someone asks for a change, it is a lot easier to see if you're breaking anything with your changes. –  m4tt1mus Apr 4 '11 at 22:52
2  
@mattimus: absolutely - an automated test suite pays off like an annuity; it is, in fact, insurance –  Steven A. Lowe Apr 4 '11 at 22:53
    
Thanks for the answer! –  louisgab Apr 5 '11 at 15:41
add comment

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.

share|improve this answer
3  
+1: You have to test anyway. Just write unit tests rather than quibble about how testing "should" be done. –  S.Lott Apr 4 '11 at 18:13
1  
Just having them locally doesn't work well in a team environment with a shared code base, other people will keep breaking your tests with their changes. –  Alb Apr 4 '11 at 20:05
3  
@Alb: That's the price you pay when management doesn't get on board - better than no tests though. –  Steve Evers Apr 4 '11 at 20:56
3  
Bravo. Any test is better than no test. If a test breaks because of someone else's change, it's a good reason to ask why the API changed without any announcement. –  S.Lott Apr 4 '11 at 21:49
    
"Management isn't going to count lines of code" that's very true. Thanks for the answer! –  louisgab Apr 5 '11 at 15:41
add comment

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.

share|improve this answer
3  
"I don't recommend writing the tests anyway" - I've been in this position before. It is hard to maintain the tests by yourself. If that burden becomes too heavy, just drop the tests. At least you had them when you were actively working in the codebase, which should help with the initial design/fix, if not catching regressions. I've found tremendous value in unit tests for design purposes, but I've found fairly few regressions when the tests are not maintained at the same level as the code. –  Steve Jackson Apr 4 '11 at 19:29
    
Thanks for the answer! –  louisgab Apr 5 '11 at 15:41
add comment

For every customer facing production issues,

  1. Write a Unit test and send an email to the manager saying that You have added a Unit test to cover the scenario.

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

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

share|improve this answer
    
Excellent suggestion! Thanks! –  louisgab Feb 8 '12 at 15:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.