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 [...]
Posts Tagged ‘design’
The No Mocks Book
Posted in post, tagged design, no mocks, tdd on December 18, 2012 | 18 Comments »
Mock Free Example 4: Everything’s Better with Async
Posted in post, tagged design, example, no mocks on July 17, 2012 | 2 Comments »
In the previous post in this series (“last week” to those who didn’t read it over a year ago), I made simple code complicated in the effort to make it unit testable. It was all going along fine, until I started bringing functional programming into the mix. Since that worked so well, I’m going to [...]
Easily Eliminate Most Mocks
Posted in post, tagged design, example, no mocks, tdd on July 15, 2012 | 9 Comments »
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. [...]
Agile vs Design
Posted in post, tagged Agile, design, feedback on May 10, 2012 | 2 Comments »
An overheard conversation at work got me thinking while I was headed home. I’ve now got to send some of those thoughts your way. The one guy was arguing against agile on the basis that it “throws the baby out with the bathwater” with respect to design. Me made several statements. Some are true, some are [...]
Mock Free Example, Part 3: Fixing Untestable Code Sequences
Posted in post, tagged design, example, no mocks on July 27, 2011 | 6 Comments »
In my character printer, at one point I had some code like this monstrosity. I know it’s a monster, because testing it Requires at least one test double (the _character field). Involves running a bunch of code not related to the unit test at hand. Many people don’t think this code is so bad. They discuss [...]
Simulating the File System
Posted in post, tagged design, Simulator, tdd on July 7, 2011 | 1 Comment »
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
Mock Free Example, part 2: Simulators
Posted in post, tagged design, example, no mocks, Simulator on July 5, 2011 | 4 Comments »
One of the common uses for mocks is to replace expensive or stateful components, such as file systems, networks, GUIs, and databases. However, I also see a cluster of other problems that arise at interfaces with these types of components, especially when they are system-level services: Primitive obsession. Rarely are these APIs written as methods [...]
Mock Free Example, Part 1: Project Intro
Posted in post, tagged design, example, no mocks, tdd on June 7, 2011 | 6 Comments »
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 [...]
How I Learned to Stop Worrying and Love the Mock
Posted in essay, tagged design, fluency, mocks, proficiency, tdd on May 31, 2011 | 20 Comments »
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 [...]
Decoupled Design
Posted in essay, tagged design, no mocks, tdd on March 12, 2011 | 2 Comments »
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.
