Go for C# developers: Where to define interfaces

When writing Go code the general guideline is not to create interfaces unless it is really needed. A good example would be an interface with only one concrete implementation. Now for the mind boggling part; in C# we would probably create that interface if the type needs to be faked in some test while in Go you wouldn't. Or actually you would. But in a different place...

Another example on ways to to make your code testable

Before you go crazy on me screaming that making code testable for the sake of testability is bad I'd like to agree. However testable code have other nice properties like loose coupling for example - something you likely want. Anyway, in this article there is a great comparison between using inheritance vs composition to implement a class and how that affects both the design of the class and the tests. TL/DR; use composition and dependency injection. Please.

Books, Mocks and Open Source

So time to look back again and update some old opinions from May 2008. This time I'd like to talk about three old articles.

Timetravel in C# done right

Testing things where you need to fake time is not hard given the right abstractions. That is why when I read this article I felt really sad. Because while the article describes one way to fake time it does so by breaking three fundamentals which is pretty hard in three lines of relevant code...

The I have no idea what I'm testing anti-pattern.

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.

IoC - good, bad and ugly

I was reading this article that is doing a pretty good job at explaining in what situations an IoC container saves the day. And even though I dislike most uses of IoC containers I've seen I have found them useful once or twice.

Abstracting time

Probably one of the most common tight couplings I see is a dependency on system time, i.e. using DateTime.Now or DateTime.UtcNow directly in your code without any abstraction around it. A tight coupling that typically leads to very complex and fragile tests when trying to ad test coverage.

Dependency injection with IObservable

Just when I started working on my little toolbox I read this series on dependency injection for events which was great inspiration.