You ever bowl as a kid? It was fun, they put down these giant tubes in the gutters, and you could just… bowl.
Around 13 or 14, it was no longer cool to use the gutter protectors, and I started bowling for real.
I sucked. Bigtime.
That is to be expected, right? I feel like if I bowled every day now, for 8 hours a day, I’d get to the point where I’d be good at the game, as good as I was when I had the gutter rails to help me.
I have been programming for 20 years now, and I gotta say, very few times has programming felt as effortless as bowling with the gutter rails up.
In one recent case, I’m helping a client modernize their enterprise web applications, and they assembled pieces from the Angular Material CDK to comprise their workflow. One such piece was the stepper -> think a “wizard” for Angular. The problem was, due to the way the application had been constructed, each of the steps of the form was actually child components that needed to communicate back to their parent that they were dirty, lest a user navigate to another step and lose their input data.
Fixing that issue didn’t feel fun., and it wasn’t. It was fighting the framework every step of the way.
Too much programming is like that these days; it feels more like bowling without the gutter rails on and sucking at it.
If you put the framework first, you have to do things the framework’s way. When you’re bowling, you have to learn how to hold the ball and use your arm and wrist to give it the right amount of spin, and you have to build the muscles necessary to do that consistently. It’s not an easy process.
The big difference between bowling and relying on framework’s opinions for your architecture is that bowling techniques still work if you pick up a new ball. If you pick up a new framework, you effectively have to start all over, learning that new framework’s opinions.
The times where I’ve been happiest programming is when I could specify the solution without worrying about how a framework felt about it. Uncle Bob et. al., speak of this as putting ‘scar tissue’ between your code and your framework; and treating frameworks as frenemies to your continued success.
There are two major and one minor way to program using TDD (technically there’s another which is entirely functional but given my audience is C# and .NET developers I’ll leave that one aside):
Outside In (London School of TDD): No scar tissue between you and the framework; you mock and stub out any form of Network IO, State, or Disk IO.
Inside Out (Detroit School of TDD): You focus solely on your solution, and take what amounts to a devil-may-care attitude to the world outside of the code you own.
FauxO – Popularized by Gary Bernhardt’s talk “Boundaries”: This method uses a similar “inside out” approach that the Detroit School does, but it uses value objects at the boundaries, and only TDD’s to the boundary of the framework; at which point it switches over to integration tests — the Framework bits are generally not unit tested.
After years of trying to make both the London and Detroit school’s work in production applications; I decided to focus solely on FauxO, and going deep on that as a method to develop production applications using TDD, without all the pain and discomfort brought on by the other approaches.
And you know what? It’s made programming feel as fun as bowling with the gutter rails did to 11 year old me, and that’s a good feeling.
What problems have you run into adopting one of these schools of TDD? Reply below and tell me about them.