I've recently started a new job and I've been tasked with completing a feature that another developer didn't finish before he left the company.

The existing tests are out of date (i.e useless)... technical debt everywhere. I think it would be a very bad idea to implement features without tests, I've put this across to him a few times and he keeps saying that we'll complete this feature and then I can do tests.

But the previous developer didn't get around to updating the tests, so it seems that my manager just says that, but doesn't mean it and keeps pushing for more features.

This latest feature is a big one, and I think it would be a really bad idea to finish it without writing tests for the whole application first. I understand that my manager has his own deadlines/pressures etc, but this feature needs to be done right, or it could come back to haunt both of us.

So how can I put this across to him in a way that will sink in how important this issue is?

I should also mention that I'm the sole developer, and the manager is non-technical.

  • 5
    "writing tests for the whole application first" - I hope you don't really mean "unit tests for the whole application first". Don't do this. Write some automated integration tests, that will make sure you don't break any existing features, but don't try to write unit tests for a whole application afterwards. Write unit tests only for the parts you are changing, as you go along and work on them.
    – Doc Brown
    Commented Jan 24, 2014 at 10:00
  • 2
    – Robbie Dee
    Commented Jan 24, 2014 at 10:07
  • thanks for the info doc brown, out of interest, why shouldnt i write unit tests for the whole application?
    – Aesthete
    Commented Jan 24, 2014 at 10:52
  • nevermind, this question has been answered below
    – Aesthete
    Commented Jan 24, 2014 at 11:09
  • Only article I know contrasting two approaches to software development within the same organisation, one being built around SOLID principles and automated testing. I think that this is as close as you will ever get to researching the costs and benefits of good practices. Are Your Programmers Working Hard, Or Are They Lazy? Commented Jan 24, 2014 at 16:03

3 Answers 3


I know this problems from my company and after a nearly failed project the management decided to put more effort in testing. But that's of course not what you need.

I would try to explain him, that the later a bug / error is noticed, the more expensive (money & time) the correction will be. Show understanding for his requirements as he also needs to fulfill his own tasks but show up, that you can not guarantee the fulfillment of requirements in time. According to that, the "project success" is on risk.

As he is the project manager he would have need to explain to his bosses why he decided as he did. (This is implicit, I don't think you have to even mention it after your explanation)

What's really important is, that you communicate an a common knowledge level. Use language he understands and ask him for his sight on the topic. This way you get a discussion on the same level and hopefully he stops to block. I hope this helps you out ;)

  • 1
    And maybe the feature really has to be done quick and dirty, and later there will be available time for clearing technical depth. Remember that technical depth is usually incurred willingly, not due to incompetence of the programmer of boss.
    – Vorac
    Commented Jan 24, 2014 at 9:29
  • That was very helpful, thanks, he understands money talk so I'll frame it that way
    – Aesthete
    Commented Jan 24, 2014 at 9:54

I'm here assuming your project has more or less been used at this point.

Do not write tests for things that are already used. Such features are tested by the users themselves. Only write tests when a bug is encountered, to ensure that it doesn't happen again.

As for the new features, however, you should test them. You should maybe even test them before they exist (TDD). Do not work on another entity before the other one has been tested, and say that a feature is "not ready" if it hasn't been tested (which is true). Perhaps even include the testing time in the estimations for every task, when you feel it is indeed mandatory.

  • thanks for the advice, is it a good idea to just rely on the users testing the features?
    – Aesthete
    Commented Jan 24, 2014 at 10:50
  • 3
    of course not, but for instance an application that has been daily used for 10 years has revealed its most common bugs already. Would you write unit tests for this? Testing is usually done before the application is released. The point is, once it's being used, you might as well just wait for bugs reports. I mean if you had infinite time, you could test everything, but here we're deciding which time separation makes more sense. Commented Jan 24, 2014 at 10:56
  • @Aesthete -- is it a good idea to just rely on the users testing the features? -- This isn't a technical decision, this is a business decision. It depends whether rapid development is more important than quality. What are the competitors like? Is it an internal app? Is there a hard release date that must be met regardless of how buggy the software is, etc. Commented Jan 24, 2014 at 18:09

If tests will help you deliver faster and more effectively, write them as you go (particularly possible in the form of asserts). He's hearing that you would like to waste time, because he has no basis for whether or not tests are a useful thing.

  • its not just the new feature that needs tests, the entire project needs tests,writing tests for a new feature and not for all of the existing ones is sub-optimal
    – Aesthete
    Commented Jan 24, 2014 at 9:24
  • 1
    @Aesthete Right, but what does he have time for? Certainly the code he's writing now is going to be the easiest for him to efficiently test, and it means that anything that breaks will be less likely to be his direct fault. Any time you start adding tests, you have to start somewhere.
    – U2EF1
    Commented Jan 24, 2014 at 9:28

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