We are about to start a new part of the project and there doesn't seem to be a lot of interest in unit testing (and it doesn't feel like they have experienced TDD). I believe it's nearly essential and it makes maintainance much easier. So what are your views?
Thanks
BTW: this is a language agnostic question, however the new project is in Java.
Yes. We have been using TDD for a while now. Somehow TDD has grown found on us and we like this incremental approach in order to achieve better code quality. In spite of the initial denial curve where you think it will slow development having consistent and progressive unit testing while writing code is essential in many ways. Writing breaking changes is very difficult to happen because of the framework of regression testings that is being incrementally built. When done right the code is more robust and the confidence in the code and in the whole project is positively affected.
Writing unit tests nowadays is not for a mere elite. It should be every developer responsibility. The later a bug is found on the code the more it will cost to fix and harder it will be to find. This easily becomes a maintenance nightmare. Having a strong support of unit tests highly reduces this risk.
Combining the power of unit tests and TDD with a well configured continuous integration system allows for rapid discovery of problems in early phases of the project. A daily build is a must to avoid future and almost sure hassles.
I find that unit testing is more than just a useful thing to do, it is also a responsibility of the developer. If you release code that hasn't been written to pass a valid and comprehensive set of unit tests, you could well be delaying your project, or causing issues in someone else's packages, classes, etc.
In addition, you should be in close contact with your customer (even if it is your own company), and try and encourage them to do comprehensive acceptance testing. It is in their best interests (although I have found that some companies are resistant to the idea, because of the short term outlay of time required to perform the testing, despite the amount of time it will save if the product doesn't do exactly what they want).
Edit
So, yes, I guess the point I am trying to say is: yes, I do see Test Driven Development as the way to go. Another thing I didn't mention of course is the fact that the tests help document the code. You will know what the methods are supposed to do, and you will be sure that they still do when you make changes at any later stage.
I've found TDD really useful, but some developers don't see the value of it until writing some new code breaks an older test.
I'm interested in doing it, but not sure how to start doing it with the large projects I end up joining part way through... Haven't been involved in a real fresh start of a project since back in 1996!
Unit testing comes at a price. First, you have to write and validate all of that extra code. And then you may have to push an expensive culture change within the project team to embrace unit testing.
This price might well be worth paying for your specific project. The decision shouldn't be based on dogma or anecdote, but on a careful analysis of the costs and benefits.
Not TDD strictly, but I do unit testing on every piece of code that I write. I think of it in the same way I think of source control and refactoring; they're something you just do to write quality code. I wouldn't think of not unit testing.
I wish I could use unit testing more in my project, and I wish my co-workers were writing at least some tests. :)
In my case, there is a quite high price for enabling unit testing and using TDD practices. It mostly depends on tools, which are quite poor for the framework we are using. If only unit testing could have been performed by a single click for a whole project (or two clicks, in case we needed a specific test at the moment), it would have been much easier. The tools we are using now don't really pay off — it's sometimes easier to spot a bug manually, rather than run the test.
With Java, there are better tools, so you really should start writing tests now! Debugging sucks, testing rocks, really.
Unfortunately not every time. Our most mission critical systems are full of unit tests to ensure they do what they should do, and keep doing it regardless of the developers. For other systems, most of the time the development time is too short to spend it on writing tests. (however in the end the time won there is spend two times on debugging. )
Yes. Except for cases when a client has a gun next my head to get a feature out of the door by the end of the day.
Unit Test (I'm thinking JUnit here) and TDD are the way to go when you are starting a new project with fresh code (and you will need more like CI).
But when your new project is to modify an old code base full of tight coupled classes with 5KLOC in each of them then Unit Testing is difficult and most of the time the project time line won't allowed a refactoring (or a rewrite). If this is the kind of project you are about to start I recommend you to read "Working With Legacy Code" for testing strategies on old code.
Absolutely unit testing is used on our projects. Every class that isn't brainless getters and setters is unit-tested. Having functional tests for you code enables you to refactor at will without worrying that you'll break 50 different things at once.
Another underrated aspect of unit testing is that it brings overlooked aspects of an algorithm to the surface. I just spent two days writing and re-writing unit tests using orthogonal arrays because each time I came up with a list of test cases, I discovered yet another dimension of the problem that was overlooked by the tech lead.
On all new development, we now do TDD. For legacy maintenance, we create failing unit tests to expose reported defects and gradually build up a library.
It is a culture shock, but it really does pay off when you realize that you are spending more time on new development and less time bug-hunting.
We do Unit Testing after a section of code works like the client really desire. At first we were doing Unit Testing too fast and when the client change his/her mind (and it occurs, trust me) you often have to delete the code as well as the Unit Test. It was too time consuming and costly. I am for Unit Testing, but TDD wasn't something economical for us.
When you ask the question on a discussion forum, a lot of people will say that unit testing is "mandatory", but in reality unit testing consideration as show by the results of survey. See http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2 for more references/material.
I cannot imagine working on a project without automated testing now (Unit/Integration etc...)
In fact, I often say
"If this breaks, its not my fault"
when working on peoples' code that doesn't have tests.
Yes, wherever I can. I have to support the code I write, and I know that a modest amount of extra time spent during development spares me from an immodest amount of extra time spent after release.