Private Implementations for Public Use is a Smell I was refactoring an older code base and noticed a pattern I used to follow where a project keeps implementations private and only leaves the interfaces public. The motivation behind this was to force consumers to depend on the interface and not concrete implementations. This is a nice motivation, but it’s only a patch to a deeper design flaw.

I previously compared the tradeoffs of Gherkin-based and TestApi-based behavior tests. Recently, I realized there is a simple in-between solution: TestApi with Gherkin-style names.

My test types diagram sparked concern that mature process focuses on repeated measured improvement, not specific techniques. This is right, but I don’t see the conflict. Tests are a kind of measure, and the diagram identifies common tests (measures) certain actors leverage to meet larger goals. This raises the question, what do the different kinds of tests measure? Consequently, what do they tell us about our system?

I recently put together that multiple verification (the quality technique) is effectively the same and as governance techniques. It’s about managing the level of trust and risk we accept from individual contributors.

I’ve been experimenting with adding a feature to the .NET SDK. Oof, this project is understandably large and complex. Here are a few lessons I’ve learned that simplify working on the project.