NDC2010: Michael Feathers – Testable C#

IMAG0104 This session was basically explaining a simple rule that regardless if you are using TDD; should be followed at all times:

Never hide a TUF in a TUC

What did Michael mean by that?

There are two things that can be “Tests Unfriendly”, features and constructs. The common denominator of the two is that they are hard to replace or isolate and thus impose a lot of constraints on what need to be up and running to test.

He then went on to explain exactly what TUF’s and TUC’s to look out for.

Test Unfriendly Features (TUF)
A TUF is something that has a tight coupling to a resource that’s hard to mock, fake or replace for testability. He listed a few;

  • File access
  • Long computations
  • Network access
  • Database access
  • Global variable manipulation
  • Use of 3rd party libraries or frameworks

The list is in no way complete but clearly shows a pattern and really follows the ideas that a unit test should be isolated from any external dependencies.

Test Unfriendly Constructs (TUC)
A TUC is a language feature that makes it hard to fake, mock or replace a piece of code. He was very clear that he didn’t say that these features where bad in any way, just that by using them we should be aware that we might introduce testability issues. Certainly in combination with TUF’s.

He listed a few C# constructs that wasn’t replaceable (or at least hard to replace without stuff like TypeMock);

  • Private/static/sealed/non-virtual methods
  • Object constructors
  • Static constructors
  • Static initialization expressions
  • Sealed classes
  • Static classes
  • Const/read only initalization expressions

    When dealing with these TUC’s, since they aren’t completely worthless, he gave a simple advice; “Do not code with the idea “why would anyone ever want to replace this” but think instead in terms of “this is really important that nobody can change or easily access”.

This was a good talk, not in terms of new things I didn’t know. But in introducing rules and arguments for building testable code. Not everyone will write code TDD-style but by at least making them following the simple rule of “Don’t hide a TUF in a TUC”  it will be easy to add tests later on if there is something you are curious about or want to validate.

This was a great take away that I see I can put into use right away.

3 thoughts on “NDC2010: Michael Feathers – Testable C#

  1. Pingback: Tweets that mention http://blog.lowendahl.net/?p=299utm_sourcepingback -- Topsy.com

  2. Pingback: What is the best practice for refactoring a static method in order to make it more testable? | XL-UAT

  3. not saying that hanvig unit tests is bad, I think it’s great. I may not have brought it across well, but my central point is that you do have to make your code base (minus tests) somewhat worse in order to write unit tests. Making your code testable does not magically improve its quality quite the contrary IMO.I think your experience suggests that a well-tested code base is worth it, even at the expense of simplicity. I don’t know if that’s something that can be said in general though, I think it depends on what you’re working on, and with whom.@Thomas:You’re not going to say that hanvig a non-standard static method to generate random numbers and some global variable to modify it’s behaviour is a simple and elegant solution? It’s a hack. Better than mine though, I’ll give you that I agree to your point about TDD, a believer will probably think that’s nice and simple code he’s writing driven by tests. From my limited experience with TDD, I think it’s because they _want_ to believe that. If you look at the code a year later, it’s not that great anymore. That random number example was from some code I wrote using TDD. Looking at that code now makes me wonder whether I was sober back then.

Leave a Reply

Your email address will not be published. Required fields are marked *