I have heard that writing (coding) unit tests for your application effectively doubles the development time required for projects. Is this true, particularly for beginners?
Also some follow-up questions (brownie points): If you were doing a client project that you hand off when finished, is it worth the time and effort to do unit testing?
I would say that double the time is a fair estimate and yes, unit testing is always worth the time and effort.
However I would contend that the time spent in unit testing is significantly less then the time it would take to debug and fix errors later that resulted from a lack of unit testing.
Unit tests also serve the purpose of documenting your code base, in terms of how do I use/call a particular class/method.
I would argue that time to write automated unit tests varies based on your language and how you do your development. For example, writing C# with a very procedural style can lead to difficult to develop tests. However, if you take a different approach, say using some mocking and IOC frameworks, unit testing time can drastically be reduced.
I guess it depends... on what amount of test coverage are you targeting
If you intend to follow the true definition of TDD where each and every line of code is tested via unit test cases- you may be looking for huge effort
But it doesn't have to be that
You can find your own balance...
In my experiences- I haven't find this to double the time- though it does add a factor (20-25% ?)
I mean- even if you didn't have unit test cases- you would still do manually unit test it- right ?
Over the time of the project- you will see that the time spent on unit test cases is recvered quite easily
For client projects- IMHO yes. They will hopefully appreciate the effort
On the topic of added time, since you mentioned you're a beginner: the sooner you can find a unit testing suite that fits your needs, the better. You haven't mentioned what language you're using, but if there is no support for reflection (C, C++ for example), it's generally going to take a lot longer to set up the unit testing facilities, because you have to instantiate the TestSuite, and the Test, and you have to register the Test, etc. That's all a lot of stuff to learn when all you want to do is run a couple tests!
On the other hand, if you're using a more dynamic language like Python, for instance, you can pretty much set up unit tests with hardly any knowledge of unit testing by making a few testXXX methods with the unittest module.
Regarding the second question, put yourself in the shoes of the client - wouldn't you like to hear that the product you've bought has been thoroughly tested? They (probably) love numbers! Tell them that you've set up automated testing, there were over 500 individual tests run, over 80% of the code has been tested that way -- well, only tell them the truth, but you get the point. It adds an immense value in the way of code confidence, and frankly I'd rather do business with someone who can demonstrate that they know what has been tested and what might be flaky, rather than someone who just hands me something and says "it's done."
What you are testing will determine how long it takes. For example, it takes me much longer to write a unit test for TSQL using the Database unit test framework from MS than it took to write the stored procedure, as it is a very manual process to prepare the test.
But, if I use Eclipse or VS2008 for Java or C# classes, and I just tell it to create the tests, then it is pretty quick to do the tests, as much of the grunt work is done for me.
It is always worth it though, as it helps to cut down on some likely bugs, but, more importantly, when it comes to duplicating a bug you will end up writing these tests anyway, and if you don't design your classes to be unit-testable then it will require refactoring, which can introduce new bugs, in order to fix a reported bug.
That is one important thing is that you will find that you have functions that are not testable, so you will end up refactoring just so you can do reasonable unit tests.
For example, if you have a function that selects from a database, then does business logic on the results, how do you properly test that? It should be two separate functions, with a controller that calls to fetch the data, then calls to do the business logic, so you will have three tests, but, the controller can go to a mock for the database as you have a separate test to test the database layer.
For my programming, I tend to only test that parts of the code that I can't intuitively look at and know it's going to work (which some people will argue isn't enough, but that's neither here nor there).
I've been programming that way a long time, and that I use those tests to help me write my code in the first place. Given that, the time to write my tests add, basically, nothing to my overall development time. If I skipped writing the tests I do, it "might" save me 10% of my time overall, if that.
When I first started using automated testing, I'd say a doubling over the overall time to write code is a fair estimate. But, over time, I've gotten to where I am not (adding next to no time). Honestly, it's something you get used to and it becomes part of how you design your code in the first place.
Edit: It occurs to me to add that there are times when writing the test code still adds a fair amount of time to my coding, sometimes well more than double. That being said, those times are few and far between as I tend to avoid code that does so... it's a code smell to me.
If youre serious about unit testing I would recommend the book The art of unit testing by Roy Osherove.
writing (coding) unit tests for your application effectively doubles the development time required for projects.
Writing tests is definitely slower than writing no tests at all if you just count the time typing out code. However if you factor in time for breaking existing functionality-debugging-fixing without the safety net of tests, the benefits will generally outweigh the costs for anything other than trivial projects. Tests aid you with Design (TDD) + Defense (Regression) + Documentation (Specs).
Is this true, particularly for beginners?
It depends. To paraphrase Beck (I think), if you're a dunce, tools/meth won't help you, if you're a coding-God, you probably don't need them. However for most of us in the middle, it helps. As you move towards the right on that spectrum, things become second nature to you, you being to 'see' whats coming and time-taken begins to reduce (although not to 0). To avoid making rookie mistakes, find someone who's already been there (get help from a mailing list or hire a good coach for a while)
Also some follow-up questions (brownie points): If you were doing a client project that you hand off when finished, is it worth the time and effort to do unit testing?
Even if the next team chucked the test suite, I'd still do it to keep my productivity up and reduce time spent creating and chasing bugs.
Not if you're using TDD because:
You actually write your test first. This is itself is a big time saver, since you've laid what you're setting out to do. You also know exactly when to stop coding. (When the test passes)
When you actually write the code, it winds up being as small as possible. You can stop coding when you pass the test, and you can then make it better confidently as long as the test is still passing.
Then write tests for the edge cases (if necessary) and check the would be problems.
I've done this and found this actually cuts down dev time - because you're already thought about what you want to do before you even start writing the actual code, and you know when when you've done it that it actually works.