44

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!

  • 6
    There's a whole chapter in artofunittesting.com about this very topic. – StuperUser Apr 4 '11 at 17:48
  • 5
    Don't mix tests and TDD, PLEASE! It makes people think that they don't need tests unless they do TDD! – P 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
  • 6
    why do you feel the need to get permission to verify your code works as expected? – Jaap May 20 '11 at 16:56
25

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://practicalagility.com/show-them-the-numbers-its-results-that-matter/

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!

  • Thanks for the response. I tried the link but it appears broken. I think I would enjoy reading it if it were available. – Joe J Jun 12 '14 at 15:07
  • Joe, sorry about the deadlink. I reposted this on my personal blog, so the link should work now. – Paddyslacker Jan 13 '15 at 20:00
  • 2
    This is a good answer but not everyone can easily compare what they are doing to some other project. I can't remember where i read it but the most convincing argument for a business person I've seen was comparing unit testing to double entry bookkeeping. Naively, doing the numbers twice is a waste of time. But anyone who knows anything about accounting would consider doing just one side of the books an unforgivably irresponsible dereliction of duties. Unit testing is the development analog to double entry bookkeeping. – JimmyJames Apr 19 '17 at 20:58
  • @JimmyJames, I agree that you can't always compare to another project, and I agree with your analogy about double entry bookkeeping. I do think if you are beginning to use unit tests on an existing codebase without tests, you can compare the code base's defect rate and other metrics between the part covered by unit tests and the uncovered code, so that you have some real data to backup your approach too. – Paddyslacker May 2 '17 at 20:34
  • @Paddyslacker I don't disagree. It's a bit of a chicken and egg thing though. If you need permission to start writing unit tests, it's hard to use them to show proof that permission should be granted. It's not either or. The comparison with real data is a much, much stronger argument. This alternate argument is weaker but easier to mount. – JimmyJames May 3 '17 at 16:42
20

Show the Return On Investment (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.

  • 3
    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
  • 4
    @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
15

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.

  • 4
    +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. – Steven 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
7

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.

  • 5
    "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
  • 1
    Whoever added features/fixes and didn't update unit tests didn't understand the concept of unit test. – Akira Yamamoto Jun 14 '18 at 7:47
  • Indeed Akira, this is one of the most confounding issues affecting the viability of TDD or related processes. Keep in mind I apparently wrote this 7 years ago, a lot is still relevant. Writing (good, objective, concise) tests is hard. Writing tests for a codebase that has none is very hard. Making non-technical management see the benefits is hard (unless they read an article about it in which case you'll get "metric'ed" to death. Even the concept of what is a unit is hard. I'm a classicist so my idea of a unit is not the same as a Mockist's (as an example with 30 characters left). – Ian Jun 14 '18 at 18:18
4

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.

  • This is good :-) – BVengerov Dec 4 '16 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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