Feeds:
Posts
Comments

Posts Tagged ‘design’

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 […]

Read Full Post »

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. […]

Read Full Post »

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 […]

Read Full Post »

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 […]

Read Full Post »

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

Read Full Post »

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 […]

Read Full Post »

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 […]

Read Full Post »

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 […]

Read Full Post »

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.

Read Full Post »

Primitive obsession is a problem because it results in duplicate code, poor cohesion, and poor coupling. What should be well-defined operations on some value become littered through the codebase and inextricably linked with other operations. Although this is commonly the result of using built-in language primitives where a more domain-related type would do, that’s not […]

Read Full Post »

« Newer Posts