I often say "how am I gonna test this?" but — language being what it is — my meaning in asking that is not likely graspable by a noob. To get at what i’m really wondering when I ask this, I may have to take a few asides & detours.
First. Why am I writing a test at all? What is the test doing for me?
This touches a mantra you’ll hear me mutter over and over. "i don’t work for you. You work for me." I tell the code this, and the ‘puter, and the "engineering process", all the parts of a development system.
The only reason I use a tool is because it is helping me (or when i’m mistaken or guessing). When it isn’t helping me I don’t use it. So what am I getting from these tests I write? What are they doing for me that earns their keep?
Several things. But I can label them all with the sort of general label: "closing the mental shoebox". This launches another tangent..
The code I work on is big. The mind I work with is tiny. In order to do the work at all, I have to bring these two scales into contact. I’m not an essentialist, but just the same, hear me: the essence of programming well is the management of mental scope. I absolutely have to arrange things so that my tiny mind can think about my enormous code through tiny temporary windows onto it.
I think of these as tiny project shoeboxes. I put a label on the box. And I put just the parts of the code I need for that label. In OO, the class is the shoebox. The name of the class is the label. The class does Just One Thing[tm]. I take out a shoebox, mess with it, then put it back on the rack and take another. That’s controlling mental scope.
The shoeboxes are hierarchical, too, of course. I have boxes that only contains a little bit of code and a bunch of other shoebox labels. In some apps, of course, those hierarchies are quite tall. Arranging the shoeboxes so it works is non-trivial. We call that "architecture". But there’s no clear line between architecture, design, and the code. It’s just a spectrum from closest-to-metal up to furthest-from-metal. And I go to great lengths — tremendous lengths — to keep those boxes small, simple, and arranged so their contents are at the same level.
So. Sliding back from that tangent. The things the tests do for me are all ways to secure the lid on the shoebox. When the lid is closed, I don’t have to think about what’s inside it. I just have to remember the label & the Just One Thing[tm] it invokes.
The first thing those tests do for me: they assure me that the box does what the label says it does. That lets me, when i’m in another box that uses this box, not worry that the box does what I said it did. Huge benefit mental-scope-wise. That’s one reason the tests make me a more-features-faster geek.
It will probably surprise you to realize this, but I refuse to let you slumber on in dreamland. You must accept this: i’m not perfect. That means that sometimes I make boxes, close them with tests, walk whistling away from them, only to later discover I was wrong. Clues in the larger world force me to open a shoebox I thot was closed, one I haven’t visited in months.
And here’s a second way the tests are working for me. The tests tell me quickly how the stuff in that box was spozed to work. I can scan a list of tests and see right away whether I thot I covered the case in question. If I didn’t, I do so now. If the new test passes as is, well, hell, must not have been that. The joy is when the new test fails. With my little failer happily in hand, I can make it green. When i’ve done that, I can put the lid back on and go back to what I was doing.
Btw, not only do I make the new one green, I keep all the old ones green, too, and that’s the third way the test works for me. Those old tests keep me from fail-toggling, where you fix thing 1 and in so doing break thing 2. Then fix thing 2 and in so doing break 1. The tests never let me do that without telling me about it.
There are handful of lesser things those tests do for me, too. They give me exempla for usage of the box, for instance. And I don’t work solo, so instructions for usage are important to more than just me.
The tests themselves are actually tiny little shoeboxes, too. That is, one test = one thing to make work. That’s a very tiny focus.
So. When I say, "how am I gonna test this?" I mean, "how am I gonna close this shoebox?" and there’s a part of this that is central, but not obvious so far: I ask that question before I have any code. In fact, I usually start asking it as soon as I start conceiving of the box. The box has API. I build boxes by building API’s I want.
And among the very earliest questions I ponder while i’m doing this: how’m’i gonna test this? (that’s not the only early question by any stretch, but those are for another muse.) anyway. For me, programming is TDD and TDD is shoebox-closing and shoebox-closing is managing mental scope.
If you want more features faster, this is the way I know how to get that from myself, and it might help you. Thanks for nodding along.