Do you have the time to write Unit tests?

Question

In your daily work, do you really have the time to write unit tests? In a lot of cases when implementing a new feature it seems that things work fairly well and we could now hand it off to the testers. Writing and maintaining unit tests often seems to take too much time.

Answer 1

Unit tests obviously take time to write. At first, you will need time to do so. But soon enough you will discover that you will actually save time by writing unit tests.

Some of the reasons are:

• you will catch regressions instantly with a proper unit test suite;
• you will be able to test much faster since you don't have a deployment in the development cycle;
• you will be able to refactor fearlessly with a unit test suite around.

---

From another perspective, many programmers have a simple main execution with a System.out to test their code. The effort to change that into a unit test is small. The benefit is huge.

---

A not necessarily time-saving issue, but also an important one is that testing forces you to have a proper class design. You will find that classes with hidden dependencies ( e.g. singletons ) or too many collaborators are hard to test. It's just testing bringing out the code smells to the front.

Answer 2

Although I am just learning, I feel that people make the time to write unit tests as part of their daily programming.

Answer 3

You'll find eventually that you don't have the time NOT to write unit tests! Fixing bugs is way easier at the early stages of development than when your code is in production. There are many many blogs that go into this far more eloquently than I can, try Misko Hevery's for a good starting place (http://misko.hevery.com). This is a good overview about testing philosophy: http://blog.jayfields.com/2009/02/thoughts-on-developer-testing.html

Answer 4

Nope, I barely have enough time to write the features requested, and I'm enormously efficient and fast compared to your average programmer. There would be no way for me to hit my deadlines and write unit tests.

EDIT: I should make the point that I maintain a very healthy work life balance of ~ 40 hours of work/week. If I worked 60, I would write unit tests.

EDIT 2: No sarcasm on my part, I could miss my deadline, or I could write unit tests. Hitting the deadline is much easier from my perspective. Otherwise I would have to explain why I'm three months off target for a year long project. Its not like unit testing was included when project time was allocated.

EDIT 3: Not that I don't want to write unit tests. I just don't see how to do it and maintain the same productivity in lines of code that actually perform a real world task. Short of adding an extra day and a half to my work week that is.

Answer 5

Do you have the time not to write unit tests?

Maintaining and debugging code which is not covered by unit tests often seems to take too much time.

Answer 6

Do you have time not to write unit tests? When things go bad, do you know WHERE they went bad? Can you refactor code and know that things will continue to work.

When you maintain tests you get a better picture of what has changed in the system. You can always throw out tests that are no longer useful (if you can't perhaps purity is becoming an issue).

I come from a background where they don't believe in unit testing and I've seen how bad things can get when we don't get the feedback you get from testing. Yes, it costs to write tests, but it costs not to test. The important thing is to find a balance; the balance is not 0.

Answer 7

We do write unit tests. We found that in the long term we save time - especially with regressions.

I found that it is much harder to come up with a testable design than writing unit tests.

Answer 8

Steve, I think You should read about Test Driven Development - nice way of creating software. At first requires some time investment, but results in both - unit tests and working code. And the time you spend creating both usually is comparable to writting only code :)

Not writting unit tests will leave you with no actual certainity, that your code works as it should - what about border cases, etc. It is really a better way of writting software. Try to test it on your own first, than give it to testers :-)

Answer 9

This is a really popular concern around here.

This one got 30 helpful answers. Is Unit Testing worth the effort?

A bunch more here Are you really using unit tests?

and The Value of Unit Testing

Answer 10

Why are you lazy ? a good unit test will take less than a minute to make and will save you hours of debugging and help you refactor with confidence ...

Answer 11

As far as I am concerned I don't have the time NOT to write unit tests.

Without good unit tests, how can I be sure that my code is correct, it works as specified, and I'm not going to get defects when I hand the code over to QA.

Unit tests save time when we get to the QA process, thus allowing us to deliver the product sooner, with higher quality. Why would anyone not want that? How much does a unit test cost? 20% of your time? How much does a tester cost? 100% of your time? The numbers don't lie!

Answer 12

Writing tests isn't just about testing. It's also about design and managing dependencies.

When you write a test there's a subtle shift that happens: you change from a developer of a class to a client. You start looking at things from your client's point of view.

If you find that your class is hard to use because its API is complete, you'll refactor it so it's easier. That's design.

If you find that your class is hard to test because the dependencies are too great, you'll break some of those dependencies to make it easier. That's managing dependencies.

The real benefit is that developers become responsible for the quality of their work. Verifying proper behavior of your work isn't the responsibility of some tester - it's up to you. If you're finding problems before you integrate your code it's far better than letting it go downstream and finding out later.

Answer 13

Ever heard of the story of the tortoise and the hare? Yes, not writing unit tests can accelerate your initial development. Over time, though, the lack of tests makes it harder and harder to continue to write code without breaking the software. Eventually, you start spending more and more time debugging your code to find what you've broken, time that could instead be used writing code. If you don't write unit tests, your development velocity eventually suffers.

When you do write unit tests, you have a safety net of code that can be used to make sure that you don't make breaking changes when you write new code. If you do make a breaking change, your tests will show you where to look and what to fix in order to fix the break that you made. Yes, your initial velocity is lower and writing tests does add to development time at first, but you maintain your velocity as the code base grows rather than decrease over time.

Slow and steady wins the race.

Once you've made the commitment to doing unit testing, choosing the long term view towards your development velocity, there are ways that are worse and better to write them. I find that I am more motivated to write tests and write less code, which is another savings, if I write the tests first, then write the code to pass the tests. This way I only write enough tests to define the functionality -- every test is useful, keeping me motivated. I also write just enough code to pass the test, no extra features, partly because I don't want to write the tests for those features unless I need them.

Writing tests has other benefits: quality, better design (to make testing easy force you to make your design decoupled), etc., but in the long run it is even faster than not writing them.

Answer 14

One aspect that a few answers I've read so far (can't speak for answers written after this one) have alluded to, but not said outright, is that if you've finished your coding and then you start to think about whether writing unit tests is time worth spending, then you are thinking about it the wrong way.

Even if you're not doing full TDD, unit testing is as much about the design of your code as about writing the tests. If you've designed your code to be testable a few things happen:

1. The code quality general improves: it becomes more cohesive, more loosely coupled, less brittle. This will tend to reduce your bug incidents straight away.
2. Your code will be more easy to test (well, that was the idea, after all) - so writing tests shouldn't have to take a long time.
3. You'll be feeling good about the code and looking forward to writing the tests - it's a sort of a feel-good feedback loop! If development time does go up it's probably because the problem space was quite complex and they really needed a good set of tests be well covered.

Don't forget, too, that during development we're finding and fixing bugs all the time. If you've designed for testability - or better still - are being test driven, you'll tend to spend less time introducing and tracking down those bugs too. So overall development time may well go down - even before you think about the bugs you missed and all the later benefits that others have talked about (confidence when refactoring, catching regressions etc).

Finally, unit testing, and TDD especially, take a while to get into the mindset of - but once you're there you'll wonder how you did it any other way - and you'll think about writing code without a unit test in much the same way you might think about walking a tight rope 50 stories up with no safety net or other support!

Answer 15

Working on a project at the moment that has no unit tests. There are several developers and many different requirements, with new ones being added fairly often. A constant theme that seems to be occurring is we will finish a feature, hand it over, and the testers will come back to us a few days later pointing out something has mysteriously stopped working in the latest build.

Not only that, but when we fix the thing that was put in to fix the thing that inadvertently broke something we are finding we are occasionally breaking something else! Quite a daisy chain going on. Id be the first person to say there might be a few bogey men lurking in our code but I keep getting this nagging feeling that we would be saving an awful lot of time if we had a good bank of unit tests stopping us going back and forth between testing.

Answer 16

Integrating unit tests into your development process is going to save you a lot of headache. Personally unit tests help me discover additional scenarios my code should be able to handle or break gracefully under allowing me to augment my code to meet these additional scenarios when needed.

Answer 17

Writing unit tests after-the-fact is almost impossible.

The proper time to write unit tests is before you write the code.

The cycle we use on our project is to write the tests to the interface, and then watch the code fail. Then we add code until the tests succeeds.

If test development comes first, then there is no issue of taking time to write them, nor is there the tendency to move on because the code you just wrote "appears" to be working as designed.

See the second-to-last paragraph under this answer at What are the pros and cons of automated Unit Tests vs automated Integration tests?.

Answer 18

In the mid-90s I was privileged to be on a team building a service-oriented middleware architecture (well before SOA became the buzzword it is today). We used an underlying library that implemented XDR, for which we had no unit tests. Since much of our software was built on this and a couple other core technologies, it was important that they be as solid as possible. Make the foundation solid, and the rest will follow. I decided to build a suite of unit tests against this software, suspecting that there were some bugs in there. Using a coverage tool, I wrote tests that covered the entire XDR library, and we found that the suite would not run on one of our twenty or so supported platforms. We fixed that bug in the library.

After that, we found that one of our nagging bugs went away in our Directory Service. It turns out that the two were related. I took some time to build the test suite, but not that much. It saved us time in supporting the Directory Service. It probably saved application and service developers time, too, but we didn't research that.

After that, when it came to the value of testing, I told everyone who would listen, "We don't have time to skip that step." And it's still true today. Can you afford the extra time it takes to skip testing?

Answer 19

I once developed an interpreter for VoiceXML (an XML-based markup for driving voice conversations between a human and a computer). Two months into development I found that when adding a new feature broke a dialog that had been working at least a quarter of the time, so that when I called my interpreter up on the phone, it would tell me "An error has occurred ... Goodbye" in it's most annoying robot voice!

So I spent considerable time implementing a mock speech synthesizer, a mock speech recognizer, and a way to run the interpreter from text files and compare the last known good output with the current output. Then I would implement test cases and features in parallel, and rerun all the regressions on each change.

After these unit tests were running, I was able to progress faster with feature development. I'd have to say one hour devoted to the unit tests and the test framework saved me at least two and perhaps three hours in development.

Answer 20

When debugging, I recreate the bug by writing a unit test that recreates the bug. I do this naturally as part of the debugging process, and it rarely takes extra time to write, since I'd have to do this anyways.

This way, when the bug is fixed, there's a unit test that makes sure the bug doesn't reappear, which unfortunately happens all too often (merges, anyone?)

Answer 21

Unit testing can't work when you are building the application from scratch, because you'll be focused on making it work, not breaking it, at first.

However, real-life situation for making unit test invaluable is refactoring. When application or part of it gets to the running condition, and users' not complaining are real proof of it, then you can say that behaviour of the system components is as it should be.

And then, you want to make some architectural changes, for various reasons, for example lifting some parts of code to meta-level, due to performance issues, due to obsolence of some library or part there of... You'll want to fix some part of existing behaviour as ''in stone'' and make unit tests for it, then refactor.