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”.
Reflections
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.
