One of the recommended links from the Code Camp was the Foundations of Programming Ebook by Karl Seguin. It’s a good read with straight-forward explanations of modern software development ideas; here are a few quotes and comments:
Maintainability is the cornerstone of enterprise development.
Much agreed, and perhaps one of the things that sets enterprise development apart from projects with less longevity. Often, though, this mandate is overlooked as schedule becomes the main driver.
YAGNI - You Aren’t Going to Need It is an Extreme Programming belief that you shouldn’t build something now because you think you’re going to need it in the future.
This is a powerful idea from agile and one that really helps you get to having something “done” and ready for the customer faster. And given how often things change, it likely saves you the pain and waste of changing or discarding something built too early.
Unit tests empower developers with an unbelievable amount of confidence. The amount of refactoring and feature changes you’re able/willing to make when you have safety net of hundreds or thousands of automated tests that validate you haven’t broken anything is unbelievable.
This is very well put; unit testing is the most systematic way I’ve seen of proving that software works for a given set of scenarios and can be refactored at will. It’s power of change is similar to having your code under source control - you always have a baseline to fall back on.
It’s a good idea to keep this API clean and understandable. The simplest method is to keep your API small by hiding all but the most necessary methods.
I’m a little torn on this one; simplicity is good, but as an API user, I like to have the richest feature set possible, without having to haggle with its authors or wait for the next release of a commercial product.
In .NET 2.0+ we can use the InternalsVisibleToAttribute to allow the Test assembly access to our internal method (open Properties/AssemblyInfo.cs and add [assembly: InternalsVisibleTo(“CodeBetter.Foundations.Tests”)].
I think the most compelling reason not to test private methods is that our goal is not to test methods or lines of code, but rather to test behavior. This is something you must always remember. If you thoroughly test your code’s public interface, then private methods should automatically get tested.
Point taken, though it still seems that if something has been encapsulate into a method - public or private - it should have its own, granular unit tests. Code coverage is definitely a useful complement to unit testing, though I don’t see coverage being carried out as an industry standard right now.
