I assume that my project is decoupled enough to allow for unit testing. But how big exactly, in terms of clases and functions, does my project need to be to make unit testing worthwhile?
Is unit testing a hard necessity no matter the size of your project?
Related: "How to convince management to "invest" in unit tests?"
Your project is big enough already
In my experience, one class and one function have been sufficient to consider the need for unit testing.
class Simple {
boolean reallySimple() {
return true; // how do we make sure it doesn't change to false?
}
}
class SimpleTest {
void assertReallySimple() {
// ensure reallySimple return value isn't changed unexpectedly
UnitTestFramework.assertTrue(new Simple().reallySimple());
}
}
Be practical
I've never bought into the "you must unit test everything" idea, though there are certainly folks out there who have (see gnat's answer!)
As far as I'm concerned, the main benefits of unit testing are:
- Helping ensure changes don't break things.
- Helping you design sensible interfaces to your classes (since it forces you to be a client to your own code).
- Helping document how your code is expected to be used.
Basically you need to weigh the time it will take you to write & maintain tests against these factors.
Number 1 is usually sufficient to make it worth writing tests. In my experience, >95 percent of code gets modified sooner or later.
Related: "How to write "good" unit tests?"
Look for common mistakes
According to Kent Beck in his answer to Stack Overflow question "How deep are your unit tests?", you should test the code that you tend to get wrong.
If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it.
Calculate the costs
Unless you are going to write code without testing it, you are always going to incur the cost of testing.
The difference between having unit tests and not having them is the difference between the cost of writing the test and the cost of running it compared to the cost of testing by hand.
If the cost of writing a unit test is 2 minutes and the cost of running the unit test is practically 0, but the cost of manually testing the code is 1 minute, then you break even when you have run the test twice.
For many years I was under the misapprehension that I didn't have enough time to write unit tests for my code. When I did write tests, they were bloated, heavy things which only encouraged me to think that I should only ever write unit tests when I knew they were needed.
Recently I've been encouraged to use Test Driven Development and I found it to be a complete revelation. I'm now firmly convinced that I don't have the time not to write unit-tests.
In my experience, by developing with testing in mind you end up with cleaner interfaces, more focused classes and modules, and generally more SOLID, testable code.
Every time I work with legacy code which doesn't have unit tests and I have to manually test something, I keep thinking "this would be so much quicker if this code already had unit tests." Every time I have to try and add unit test functionality to code with high coupling, I keep thinking "this would be so much easier if it had been written in a de-coupled way."
TL;DR: Write a test when the cost of writing the test, plus the cost of running it as many times as you need to is likely to be less than the cost of manually testing it as many times as you need to.
Remember though that if you use TDD, the cost of writing tests is likely to come down as you get better at it, and unless the code is absolutely trivial, you will probably end up running your tests more often than you expect.
Length doesn't matter
Eivind Eidheim Elseth Answers (79 votes):
I believe that it's not the size of the project but the type of project which decides if it should use testing or not.
If you are working on a proof of concept, or on some other project where the goal is to learn from the coding, then testing is not required. If the project is meant to be used, maybe even sent into production, then it should be tested.
A quote from Robert C. Martin's "Clean Code:" "If it's trivial to write, it's trivial to test," so there's no excuse to skip on the testing for short and trivial programs.
Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.
reader comments
71