My intent in writing a test is to satisfy myself by the cheapest means possible that the code does exactly what I think it does. I stress that this is my intent. Believe me, fifteen minutes on the internet will reveal to you a barrage of other possible intents.
Surely, by now, it will be clear to you that i’m not an essentialist, but an extreme pragmatist w/strong existentialist leanings. My intent is to use the test to underpin my ability to offer what I call the geepaw guarantee.
The geepaw guarantee: it does exactly what I said it does, no less. It does it every time in every context I can imagine it encountering. I call it a guarantee. I mean, if it doesn’t do exactly what I said it did, call me. 24/7. I’m outta bed, i’m outta the bar, i’m on it.
Notice, by the way, we’re already swimming deep into a lake of imperfection.
There are holes there. Two come to mind immediately.
First, who says that what I said the code did is what you wanted the code to do? Sure, the code does add two integers, just like I said it did. That doesn’t mean it wasn’t supposed to — from your view — multiply them.
Second, while my imagination is indeed pretty fertile, it’s not sufficient to anticipate every conceivable context in the universe. The geepaw guarantee doesn’t extend to cover quantum effects or non-Turing architectures or opposite day.
Those are real holes. I have to live with them. On another day, i’ll argue that you have to live with them, too, but not for now.
And I slid over a phrase I have to come back to now: "as cheaply as possible".
That’s a key part of my intent, and it’s not ignorable or reducible. It’s dictated by what i’ve elsewhere called the money premise. I won’t elaborate much here, see "Five Underplayed Premises Of TDD". The only reason the rest of the intent stands is because I want to make more features faster.
It does me no good to prove that what I said is what it does if the expense of doing that keeps me from adding more features. A non-TDDer will object, here, then why write tests at all? Every test adds code, after all, so, like, math, dude.
It’s because no serious code is not dependent on other code.
On day 0 of your greenfield project, for a good half-hour or so, you are free of dependencies on your own code. After that, it’s self-dependency all the way down. Being sure that I can depend on the code I wrote yesterday is a gigantic factor in being able to add more code today.
I can’t stress this enough. I want to know yesterday’s code works entirely so I can add today’s code as fast as possible. The money premise. So that’s my intent in writing a test. To satisfy myself as cheaply as possible that it does what I think it does.
Since virtually all future conversation depends on that intent, I wish I had a name for it. I feel stupid and semi-corrupt when I propose calling it "the geepaw intent". I could call it something that sounds more rigorous. But there’s no more compact form I know of than the statement itself. Anything else is just a shorthand label.
I’m open to a better name. For now, i’ll call it the geepaw intent. In the follow-up musings, that’s the shorthand i’ll use, nless someone comes up with something better, and then i’ll make a fuss so readers can understand the switchover.
Later, maybe tomorrow, i’ll take another step deeper into unravelling this automock thing. Until then, geek on.