6

Possible Duplicate:
TDD vs. Productivity

In most computer science books such as Clean Code we are told to write good Unit Tests in order to increase productivity when updating project or writing new modules (or refactoring). Most of my project are short and take about 2 months or less to develop and often they will never be updated once they are completed.

My question is considering that, is it really useful for me to write a good unit test?

Maybe it would be faster to plainly test my programs with manual input?

Improve this question
3
  • 4
    This has been covered pretty extensively on SO: When to unit test vs manual test
    – ire_and_curses
    Jul 18, 2011 at 20:31
  • If you start from scratch - then usually yes. If you have inherited a steaming pile of code - god help you.
    – Job
    Jul 18, 2011 at 22:59
  • 2
    I'll never understand why so many people believe that a manual test could be faster than a unit test. Are you faster than a computer? Not doing any testing will certainly increase productivity... if reliability is not a concern. Otherwise, it's Westheimer's Law rearing its ugly head again.
    – Aaronaught
    Jul 18, 2011 at 23:03

4 Answers 4

Reset to default
6

I have found unit tests to help my productivity:

  1. They help me work out how I'd like my code to be organized (classes, methods, etc).
  2. They help document how to interface with the code.
  3. Looking at one unit in isolation helps focus on edge cases and hidden assumptions that could bite later on.
  4. Chunks of code that are reused will have tests already written.
  5. Both refactoring and bug fixing can be done more efficiently, since you can immediately test whether you broke something else.

If your programs are actually on such a short timeline, and never get updated (even for bug fixes?), then it may make sense to find the right balance between the thorough unit test you'd use for an operating system library and the quick-and-dirty handful of manual tests you'd use for a one-time-use program.

A couple of extra suggestions: First, your productivity with TDD and unit tests will improve with practice. Second, learn and make use of available features of your development environment and addins that accelerate development of unit tests.

Improve this answer
3

I find that TDD does have use in even "casual" programming:

  • It forces you to think of how you will use the code. There have been a few times where I have been given an object someone else has just coded out, or have even coded myself out of context, that turned out to be a nightmare to integrate with existing code because an entire additional layer of abstraction, concretion and/or general adaptation is necessary. In TDD, usage, and thus a hint of the required integration, is the first thing you think about.

  • It tends to lead to more encapsulated designs that are easy to "drop in". Unit tests are, by their very nature, tests performed in isolation, and you generally want the tests to be simple so you can get them done and quickly find the problem should something fail. Creating an object that is easily tested in isolation thus generally results in a very simple loosely-coupled external "interface" that helps make your code modular and easy to work with.

  • Only the very simplest projects can be comprehensively tested by hand. Unit testing requires more development up front, but reduces the amount of testing that has to be done as each new feature is added. By running your unit tests, you prove that not only what you are writing now behaves as expected, but that what you built the new stuff off of STILL works as expected even after messing around with it to add the new stuff.

  • It encourages behavior-driven design. You write a test suite knowing what the object under test will have to do. This discourages "premature optimization" and encourages adherence to YAGNI.

Improve this answer
1

One thing that unit tests surely achieve for me, is increase my confidence. I feel safe to edit, rewrite, or refactor existing code, with the confidence that if I did something wrong, the tests will fail. If not, I know that my modifications were correct. In a way it's a confirmation for the behaviour of code.

(Of course all this assumes that the unit tests are correct and thorough. This does require time, but in the long run it pays off)

Improve this answer
0

I think it depends on the type of project you are working on.

I had an experience where we wrote a bunch of unit tests on a project without a clear domain model. When the domain model was refactored, a lot of the unit tests became irrelevant and had to be rewritten. By the third iteration we gave up on them, we had never used them and they had to be rewritten once again.

Improve this answer

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