Programmers cling to integrated tests in part because of a feeling of security. I consider this a false sense of security, but it only seems fair to answer the common question of how I keep contract tests and collaboration tests aligned.
When it comes to organizing collaboration and contract tests, I don’t do anything special: I mostly follow the two elements of simple design.
Every year I work with programmers who overcomplicate dependency injection. This causes stress and it influences other programmers to not even try this technique at all. I’d like to put your mind at ease with some advice to keep things simple.
I just learned about
zmv and I love it. Copying and renaming paths with regex? Very handy, indeed.
People frequently ask me for “advanced TDD”. I have good news and bad news.
By following a few simple design principles, you can make code safe to use without making it difficult to examine nor adapt to new purposes. Give me guard rails, not prison bars!
If you’re thinking about starting to use Contract Tests, don’t look for tools, because they don’t help you with the most important aspect of Contract Tests, and they might even distract you from it.
Years ago, I learned a simple heuristic to discover when subclasses are ready to die. In functional programming, it appears that we can use that same heuristic to surprisingly good effect!
I’ve been teaching programmers about the value of isolated tests for a long time, and recently I’ve seen increasing resistance to the idea. I worry that this comes partly from having presented motivations and reasons that tends towards the overly-abstract, ironically enough. Perhaps I can improve matters by returning to the concrete issues and constraints that led me to being exploring this idea in the first place.