I haven't done the unit testing thing really but I am curious for those of you with more experience with unit testing, is it really practical to write unit tests for all your classes and methods?
Or to be more realistic, should one just focus on the business logic aspects?
2 answers
It depends on what you're working on, but as a general rule I'd say it does matter. If your codebase is a v1 and has a road map for many more features and extensions then it would be absolutely necessary to have unit tests, this way you can include them in the CI process so that when you add or modify your code base, you know immediately whether it will cause a bug somewhere else.
on the other hand, if you don't have unit tests then 1-3 years down the line you may come up with some issue that would have been caught in a unit test that may have taken 2 extra days to write and you'll end up spending more than a week searching for the cause of the issue.
It's a matter of whether you want to pay for it now or later, and IMO it's better to pay for it while you still remember all the requirements for the class, package, or system.
answered 2 years ago by:
2309
246
What is CI? I see what your saying, but writing all these tests, mocking out db layer, etc. But I can see how it is worth it. But even maintaining tests is a fulltime job!
2309
CI = Continuous Integration http://en.wikipedia.org/wiki/Continuous_integration. It always seems like more work than it's worth at first, especially for small tasks, but visual studio has automated that somewhat (at least the boilerplate code necessary), but it's a good practice to get into. At a minimum public SDK's should be unit tested (core / common / shared libraries). It's a lot like paying insurance, you don't need it 99% of the time, but when you do, it's really good that you have it.
246
thanks, great answer.
One benefit of writing unit tests is that it is a great way for new developers to understand how the software is to react. They can learn the edge cases etc. also.
As far as it being practical, it really depends on how you view things. Harder work early on versus maintaining your buggy code down the road.
For the record though I haven't soaked myself with TDD or anything, just getting into the unit testing mindset myself (but I am sold on the idea, at least theoritically). One thing that does scare me away is maintenance of your unit tests (i.e. API changes, now you have many tests to go through, but that is not a everyday occurrence).
At the very lease, I would suggest writing unit tests for the core business logic of the application.
e.g. say you have a shopping cart, you should write tests for adding/deleting/coupons/security checks etc. etc.
answered 2 years ago by:
510
2309
but the great thing about TDD is that when you make a change to your API you are thinking about testing before you touch code. Combine that with actual planning (design documents and such) and the overall quality of the product increases and time spent modifying it will greatly decrease. A great side benefit is also that new developers touching the code will also have more to go on and will generally require less of a ramp up time.