I find one of the important early mind shifts to be a switch from thinking of unit tests as test to thinking of the set of all tests as your spec.
If your spec is clean, you could delete your product code, hand it to someone, and they would implement the same product, with roughly the same design.
If your product code is clean, you could delete your spec. Hand the code to someone and they could extract the spec from the code, ending up with a similar spec.
The first of these is called TDD. The second is called working effectively with legacy code. Continue reading “Your test are just your spec. NBD.”
Recently on twitter, Clayton asked for a good book about unit testing without mocks. I don’t believe such a thing can be written, so I’ll try to write it in one blog post. First, here it is in one sentence:
Mocks are a smell. They tell you that your code depends on some semi-related part of the system. Rather than work around the design defect, fix the design.
The trick is figuring out what smell you are observing and how to “fix” it. Basically, what alternatives exist. Down the rabbit hole we go. Continue reading “The No Mocks Book”
In previous discussions about mock-free unit testing, I’ve shown techniques that I use to eliminate the hard-to-eliminate test doubles. I’ve skipped the simple techniques that I apply all the time. Time to fix that.
One technique eliminated about 90% of the test doubles in my code. It’s simple. It’s been around for a long time. Odds are you already do it but not frequently enough. It even has a name:
Extract Method. Continue reading “Easily Eliminate Most Mocks”
I just published an early relese of my Simulated.FileSystem library. This library makes it easier to separate platform concerns out of my models. It works really well with a hexagonal architecture.
This library will define a set of ports for common external dependencies, with multiple adapters for each port. The initial release just includes a file system port, with two adapters: native file system and in-memory file system. Continue reading “New Simulators Library”
I recently posted an entry about replacing mocks with Simulators. That one used a Simulator from my running example code. Here’s another example, which may make the concept more clear.
This is a file system simulator. I’m building it out as a generic simulator, re-usable across projects. Right now, I’m using it Continue reading “Simulating the File System”
Previously, I presented mocks as nuclear weapons. Unsurprisingly, commenters wanted examples. I exist to serve.
This series will discuss a partly-completed project that I have lying around. The project isn’t perfect. But it will serve to discuss some of the ideas. Since it’s only partly complete, some ideas visible in this stage that would likely become much more subtle with another few days’ work. Or so I hope.
It’s also a full project. The ideas blend into each other at the edges. I am not creating an example to demonstrate an idea; I’m showing how those ideas interact with each other in the wild. This will make the examples more difficult to follow. Sorry. I’ll do my level best to guide you to the areas that I find interesting (whether positive, negative, or simply unfinished).
Continue reading “Mock Free Example, Part 1: Project Intro”
I learned something very useful from Marty Nelson’s blog entry on the proficinecy levels of TDD. It was the first time that I saw a construction which included mock objects as a good thing and that also passed my sniff test. So, I hereby recant: Mocks are no more Evil than are nuclear bombs. I’ve learned to love them, as the tools of mass destruction that they are.
Actually, Continue reading “How I Learned to Stop Worrying and Love the Mock”
At a talk today, the presenter put the following simple unit test on the screen and asked me what part I would write first. Continue reading “Tests – What Part First?”
Recently, I’ve had a large number of discussions around the use of mocks for testing, probably because I keep saying that Mocks are Evil.
As a result, I’ve had to articulate how I design systems. Continue reading “Decoupled Design”