Re: "It's OK not to unit test" or what you do on your time is your business.
Read this. Don’t skim, read the whole thing. Then come back here. I have a thought that I wish to express here and it may be controversial to some. You’ve been warned.
The issue in this cashto’s blog entry hovers mostly around platform and language. Simply put, unit testing is the art of testing small units of code. In Test Driven Development you do not write new code until you’ve written a test that clearly articulates your intent. You essentially use the code that you plan to implement via a test and only then write the implementation behind the api that you’ve just crafted. That process has a side effect, commonly referred to as “Emergent Design”. One commonly documented side effect of Emergent Design is that it encourages highly modular, de-coupled sections of code that have high cohesion and low coupling. In some circles, these are indications of a healthy code base.
Now, having spent a great deal of time in C# and about a year doing Ruby professionally, I can say that the approach that I prefer to take, BDD, is significantly more complex in a static language on a proprietary platform than when writing similar software in a dynamic language on an open platform. Therein lies the difference. When I read articles like this, I see them almost universally from the static language camp. By camp, I mean to imply that these are folks that have chosen to work in static typed languages on open and closed platforms. The bemoan the time it takes to craft tests, ponder their significance and after some frustrating exploration chalk it up to another fad but ivory tower academics. The problem with this assumption is that these techniques are solving big problems for folks like me who, in a dynamic language, needs a little more coverage to ensure that the expectations I’ve defined for the system are being met. Unit testing provides this. If I were interoperating with SharePoint’s object model (and I have… extensively) then I would not worry about unit testing. Why? Because the effort that it takes to isolate the units provides diminishing returns against how I will write it. So, if you want to skip it there… I’m not gonna hold it against you. BUT, if you write a Ruby gem that I plan to use and I install it and run the tests and there are no tests then you’re not playing nice and I WILL hold it against you.
Yes, my expectations for cultures and communities is slightly different. That’s me. that’s my experience. How about an analogy? In static languages, I believe that Dependency Injection is a valid and powerful pattern. In Dynamic languages it’s a waste of time that provides no value. Does that mean that DI is bad because I prefer a dynamic language? No, of course not. It only means, given my circumstances, DI is worthless. Is DI worthless? no. Make sense? Yes. Sound overly politically correct? Yes.
This is all to provide the following context: The blog above was written by a man who works for Microsoft on Microsoft products. Given their slow uptake for developer testing support and de-emphasis on unit testing and TDD(ing) .NET projects. That’s the experience that has shaped cashto’s reality and you should know that when you read that article. It’s no wonder, to me, that when developers look to gain from the experiences of developers outside their home platform they grow frustrated and no amount of practice ever seems to make the problem go away. The reason is not that they don’t understand or haven’t tried the idioms they see rather that culturally, it is not valued in the same way that watching the compiler fail is, or in the case of ASP.NET, the same way pressing F5 and getting a mini browser REPL going is.
When I worked, briefly, at Telligent their code base was written using that “Microsoft” model. I often tried, sophomorically, to get the entire team to see the benefits of testing, because I was needed it in my own workflow. As the other developers either sided with me or against me I noticed how smart people with lots of experience can simple never come to an agreement. If I wasn’t laid off, then it was clear to me that we were probably never going to be a match made in heaven. That’s not a slight on Telligent, they were a great employer and I got to work with some very highly respected developers in the Microsoft domain. It simply proved to me, that I didn’t belong there. So, I joined EdgeCase. Suddenly I’m not fighting anymore. I’m not arguing. I’m back to the business of writing software and not fighting ideological battles and writing “memos”.
So, is it “Ok not to write unit tests”? Sure, of course it is! If you wish to do so, it’s quite alright. The chances are, though, you will find it difficult to relate to and work with an increasing number of talented software craftspeople who believe in automated testing as a fundamental aspect of their workflow and that would be the real shame.
