What is the best reason for unit testing?

Question

There's a lot of discussion about unit testing these days. Here's a poll for the best reason to do it.

ONLY ONE REASON PER ANSWER PLEASE!

Answer 1

To make sure your stuff works.

Answer 2

To find any issues / bugs in code you've just written.

Answer 3

Confidence - Prove it works.

Answer 4

To make you think about your code.

Answer 5

To make sure the guy who changes your code doesn't screw it up.

Answer 6

So that when you refactor your code / add a new feature, you can be sure that it still works.

And to ensure that it works the first time round (hint, write the unit tests first)

Thinking about the code is a nice incidental benefit of writing tests, but is not the primary reason to do so. I can think about my code without writing a test, but thinking about it is not a great way of testing it.

Answer 7

To reduce the time spent testing.

Answer 8

Catch regression errors.

Answer 9

Confidence in your code that it won't break due to modifications/refactoring.

Answer 10

To ensure that your code works when changes are made anywhere in the code base.

Answer 11

To help later on when you need to refactor your code. Whenever you refactor your code, unit tests insure that the new code works as expected.

Answer 12

So QA will be slightly less likely to beat you over the head because your feature causes the system to crash.

Answer 13

Because the later in the development phase a bug is caught the more expensive it is to fix.

Answer 14

Create Reusable code - Easily Testable code is Reusable code. 1 Function has 1 Function.

Answer 15

To make sure your code works, even in conditions that will not occur often.

Answer 16

To reduce the amount of manual testing & debugging

Answer 17

Unit tests make all the known responsibilities of the code explicit and transparent, giving a much higher degree of confidence that code will meet expectations, and giving a good indication of areas where behavior is not tested/thought out, too.

Remember that the unit tests in test-driven development are about programming - NOT testing!

Answer 18

To simulate situations that may not be possible to produce until the code hits the real world

Answer 19

It forces you to think about your code from the point of view of its consumer, which can lead to improvements.

Answer 20

Unit testing leads to loosely-coupled design/modules.

Answer 21

The best reason to write unit tests is to make sure that the code under test does as you the developer think it should be doing.

Whether or not it meets requirements is outside the scope of the unit test, and can be more aptly described as acceptance testing.

Answer 22

When you are trying to track-down a bug in your integrated program, unit-tests will help narrow-down the root cause.

Answer 23

Without them, coding in a dynamic language like Ruby becomes a complete disaster. Anything that would allow the following code to compile and run and assert correctly needs help from testing, typos are too easy.

bill=5
bi1l=bill+5
assert bill=5

Answer 24

Because it's easier for a machine to test each object/function with 10,000 possible (and impossible) values than for a person to sit down and use the program in 10 different ways.

I worked in a company that made software to do survey design and reporting (the people who come up to you on the streets with a PDA and ask you a series of questions). When I was hired, they were in the process of releasing their latest, greatest version.

The task that I was given right away was to take a copy of the beta they had so far and load up a bunch of test surveys (by hand) onto a device, and go through them putting in specific answers and checking to see that the result set I got at the end was what it should have been.

Had their code been properly written and modularized, with specific interfaces, they could have written test suites for each component. Then, the two weeks I spent doing testing could have been done automatically in seconds, and we would have found out that our biggest feature in our Enterprise version was completely broken BEFORE announcing it to the world and getting everyone to switch, saving us a lot of egg on our face.

Unit tests tell you when your minor changes have introduced unexpected bugs, and when your major changes have obliterated your functionality completely. You'll never have to worry about forgetting to test a component, and if you get really fancy and integrate it with version control, the system could, upon discovery of a regression, iterate back through each revision until it finds where it broke, and generate a report on who breaks the code most.

Answer 25

Well... it may seem a bit silly but I do it because it's fun! (Thinking about it I remember that Kent Beck said something like that in one of his books)

Answer 26

It is a 'living', working design document of what your code should be doing.

Answer 27

Decreases turnaround time. Instead of booting up an entire app, just run the unit test.

Answer 28

It's great fun.

Answer 29

It's a great way to bake in quality design at a low level

(oh yeah it is fun too!)

Answer 30

I'll add mine, unit testing supports refactoring, by having good coverage with your unit tests you can change the underlying code without fear of breaking existing functionality. This lets you concentrate on keeping your code flexible and only implementing the functionality that you need

Answer 31

all the other answers are taken, so i'll just add: unit tests make great how-to-do-X examples for others

Answer 32

It is a systematic way to build confidence that your code does what you expect it to do (you write unit tests to interfaces, not behavior).

Answer 33

It saves a lot of time and programming effort in the long run.

Answer 34

If you write your unit test first it will actually help you write your actual code. I can't count how many times I started writing the unit test and immediately thought "dang, I didn't think about handling that condition".

Plus, once you get one unit-test done, you now have a 'template' to create a full-regression of unit tests for all the new features that the boss wants.

Don't forget to put them in your Makefile - you want a simple way to kick off a unit test or a full-regression (e.g. "make xxx-test" or "make test-all"

Answer 35

i'll throw in another reason: unit tests can often provide convenient ready-made demonstrations of particular features - for when you have to concoct a demo for a VIP on a moment's notice

Answer 36

TDD leads to better design which in turn leads to understandable code and easier refactorings (because of better implementation of SOLID principles like Single Responsibility Principle).

Answer 37

There are many reasons, lot of them are orthagonal. You gain from all of them, so pool for the most important is a little bit pointless. Whatever. There is one quite important one, that noone has mentioned so far.

Communication.

Remember, Programs must be written for people to read, and only incidentally for machines to execute.

• Tests are documentation. You look at the test of a class, and you know how to use it and how it behaves (including corner cases).
• When you're doing TDD and pair programming writing test before code forces you to communicate other person what do you expect from newly created functionality. It's really helpful when pairing with non-talkative parson

Answer 38

one-answer-per-post beats double-posting-is-bad, doesn't it?

Long-running tests are #2 excuse for legitimately slacking off.

Answer 39

So that someone in QA is not the first person to run your code.

--
bmb

Answer 40

Fast feedback loop.

Answer 41

Force yourself to think about weird, pathological corner cases sooner rather than later or never. Personally I believe developers have a blind spot for thinking outside the happy path as we develop code UNLESS we are unit testing as we go.

Answer 42

TDD gives you a set of unit tests that act as executable documentation for your production code. That documentation gives you long-term confidence in your code and a way for developers (including your future self) to understand your code in the future.

I don't think there's one single best reason though. Lots of the answers here describe equally important benefits.

Answer 43

Because; when unit testing you get to be the consumer instead of a supplier.

Answer 44

To be able to say yes with a smile on your face when the product owner asks "Can we add this new great feature?".

Answer 45

To give you the freedom to refactor.

Answer 46

Untested code is broken, untrustworthy, and unverified.