People around me often hear me mumble things like "I think we are missing a level of abstraction here". This is something that often happens when I help people understand how to efficiently unit test a piece of code. But right before Christmas I was working in some code that perfectly highlighted that all abstractions are not equal.
It is no secret that I'm not a big fan of service locators in general, but even if you are a fan of those there is a pattern I really don't want to see in unit tests. I will call this the I-have-no-idea-what-I-am-testing-anti-pattern.
So this happened a few years ago in the days between Christmas and New Year. I was using the slow days after Christmas to get some work done in the office when suddenly a guy from the operations team came running down the hallways shouting "a developer, a developer, a kingdom for a developer"!
There is one part of implementing an API using TAP that I've always found cumbersome and that is the guideline to throw argument exceptions before the task is started. I've always been glad that I never had to make the call since I haven't been developing externally available libraries, but recently I had an interesting discussion at work that made me reevaluate my standpoint. Maybe...
This slogan (never hide a TUF in a TUC) was introduced (to me at least) in 2010 by Michael Feathers. Turns out it is a pretty good tool to explain and steer people in the right direction when they are new to writing unit tests. But what is TUF and TUC?
If you want your system to have good diagnostics (aka logging) I find there is a kind of catch-22 in achieving it. And that is regardless of if we are thinking about diagnostics in order to understand why things went wrong or if it is to do business analysis. And rather than calling it catch-22 I'll call it a paradox. Because it sounds cooler...