I develop small projects, and the testing is usually a functional test when I verify if the service is working as I were the user. Is this ok with small projects of 2-3 people? How do you think unit testing could help?

This isn't so much an answer, but if the project is important enough to have 3 people working on it, it's important enough to get some testing on it too. I am torn about whether my single-person project should have testing on it!
–
corsiKa♦Oct 4 '11 at 20:44

5 Answers
5

Like you said in your question, you currently test your code functionally. Why are you doing that? Because testing is useful! Unit tests are the same. If you ever go back to refactor your code, add or edit features a suite of unit tests will give you instant feedback that your changes aren't breaking anything.

I'd really recommend trying out Test Driven Development. You think about what you need, right a failed test and then add the code to make it pass. Lather, rinse, repeat. Here is a good list of benifits from writing code this way, or run a google search on the topic, there are many resources out there. TDD is easy to understand, really hard to master.

great answer! I don't always do test driven development but writing even a few test can help write better code that will help when that "small project" becomes the next big one. ;0)
–
bytebenderOct 4 '11 at 20:47

Absolutely you should write unit tests. There's no guarantee that your small project isn't going to get added to at some later date - or that the next version of your operating system won't deprecate the calls your project is making to something. Or any of innumerable other strange things won't happen. It's not that uncommon for someone's prototype to become the core of a new application, and morph into a maintenance nightmare because the original assumption that this was throwaway code wasn't correct.

If you can avoid getting bitten by any of these possibilities, avoid them. As far as that goes, unit tests are the condoms of the software world: they protect against all sorts of unforeseen events, as well as against the things you expect them to protect against.

Testing is a means to an end, not an end in itself. If you are satisfied with the quality of your work using your current development and testing practices, there is no need for additional work. If you are not satisfied with the quality of your work, writing unit tests is one possible path to improvement.

I cannot guarantee that writing unit tests will make things better for you. In some circumstances it can be a waste of time, e.g. when the developers do not want to write unit tests, or when the unit tests focus on things that are unimportant or unlikely to have bugs. In the right circumstances, they can make a big difference. When I was a developer, I wrote unit tests, and for me it was a productive practice.

Full answer

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.

Then I started to use Test Driven Development and 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 focussed classes & modules and generally more SOLID, testable code.

Every time I work with legacy code which doesn't have unit tests and 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".

Comparing and contrasting the two experimental stations that I support. One has been around for a while and has a great deal of legacy code, while the other is relatively new.

When adding functionality to the old lab, it is often a case of getting down to the lab and spending many hours working through the implications of the functionality they need and how I can add that functionality without affecting any of the other functionality. The code is simply not set up to allow off-line testing, so pretty much everything has to be developed on-line. If I did try to develop off-line then I would end up with more mock objects than would be reasonable.

In the newer lab, I can usually add functionality by developing it off-line at my desk, mocking out only those things which are immediately required, and then only spending a short time in the lab, ironing out any remaining problems not picked up off-line.

Project size should not be a factor to consider for skipping unit tests.

Most people here will hate me if I give you good reasons to not unit test. These are the only three I consider:

Time pressure and poor testing experience

If you are running under time pressure and do not have good experience testing your software. Do not start now. On the long term testing your software is a huge productivity gain, but on the beginning you will work slower. Learn TDD when your deadline/job is not at stake

Usage frequency

If you are working on something that you will only run a few times, delete later and a bug will not destroy your life, then it is OK not to write unit tests

Maintenance

If your tool does only ONE single thing and you are quite sure that you will never have to touch it again (hardly ever the case), then it is also OK not to do unit testing.