Writing “too many” if conditions can cause problems in code, but I think we’d all feel better understanding why this might be the case, rather than merely repeating received wisdom.

The production implementation of an interface can fail, but the lightweight implementation that you use for testing can’t fail in the same way. How do you check that the client is handling that kind of failure? Use another kind of test double.

To some it feels a bit wrong, but it feels quite natural to me: I often need to refactor just before writing the next failing test. Indeed, that seems like a good practice on its face!

You understand the benefits of refactoring, but you still feel a strong impulse to rewrite larger pieces of your system. You believe that refactoring would be safer and more effective, but it feels too slow for you to choose to do it under the pressure of an industrial-strength situation. What does that mean? What can you do?

If you read enough articles on TDD and testing, you’ll find authors who view mocks with significant suspicion. I think that they criticize the symptom and not the cause. If you count yourself among these people, then you don’t hate mocks, you hate side-effects. I don’t hate side-effects, but I feel glad that I’ve learned how to refactor away from them.

If you’re wondering about whether you should hand-roll your test doubles (mock objects) or use a library, then this article will help you.

When trying to write code incrementally in Elm, I ran into a problem because Elm tries not to generate Javascript for Elm code not (yet) in use.

Many senior programmers feel nervous allowing their project’s design to evolve in the hands of their co-workers. This article shows one specific example of how a useful abstraction and a small type hierarchy can evolve by following simple design guidelines that anyone can learn.

A software contract is not a legal contract, so let’s not treat it as one.

If you write a Spock test, but forget to subclass from Specification, then you might not notice the mistake.

Doing (test && commit) || revert amounts to doing TDD very carefully, as an étude. If you already routinely take tiny steps, then you already almost do TCR, but something significant might change if you do it exactly. This remains to discover. Join me.

I have a new Linux laptop and I wanted to run C# code. I had no idea where to start. I last wrote C# for money in 2004. It took me over an hour of hunting to figure out how to run a single test, so I decided to write a tutorial that could help someone else go from zero to NUnit with Visual Studio Code.