Thread by @GeePawHill

Not everything I write using JUnit is a test, is TDD, or is an artifact I want to keep.

Of course, by JUnit I mean "my testkit". I happen to be in Kotlin right now, so JUnit is it, but testkits that are made for unit testing all have the properties of JUnit that I'm actually taking advantage of when I use it in these ways.

Good testkits give chunks of code a name. They expose those names in a way that is easy to choose and subset. They *run* those chosen chunks in a way that does not involve you launching the app and flipping through screens. And they do it over and over again with one gesture.

Some of you have lived your whole lives in REPL. Others *never* used a language that is interpreted or micro-compiled. A good testkit carries some of the benefit of REPLs. A good REPL carries some of the benefit of a good testkit. (Neither is a perfect substitute for the other.)

I often make a new test case, add a test called "idunno", and develop a small algorithm right inline in the case. No separate files, packages, etc. just the whole thing in one file with its "invokable handle" the testkit's UI.

It's fast, it's simple, it's a great way to play around. By the way, if you're a relative noob, I do hope you're learning the extraordinary value & need for playing around. That's prolly a whole muse in itself.

When I do this kind of thing, there are different outcomes in different situations.

Sometimes, I walk away feeling I learned nothing and I got nothing and I hate you hate you hate you. I just throw it all away. (Put an Edison spin on it if you want: "I successfully proved *this* won't work.")

Sometimes, I learn something and I feel strong and life is just a bowl of cherries. It may surprise you to hear that, even in that case, I often still throw it all away.

Again, for the geek-young in the crowd, I hope you're also learning that the scarce resource in programming isn't code, it's understanding. It's far easier to make or re-make code than it is to make or re-make "grasp".

Of course, sometimes I learn something etc., and then I *keep* the code. I do this when I feel I have high certainty that I got it. I refactor the test until it's extractable code, I extract it and move it to the prod part of the tree, and start using it.

Rarely, when I keep the code, I also keep the tests. That usually means I had great luck. I got the right abstraction exactly, I got code that implements it, I got tests that probe it, though I usually have to go add the assertions, which I wasn't even using at that point.

I repeat: that's rare, not an everyday occurrence. When I am writing production code, I am following a substantial set of beliefs about what "good code" means. When I am playing around, I am, well, playing around. Anything that gives me the insight or inspiration is good enough.

I use "tests" like these -- they're not tests, they're just named chunks of code that easily runnable & debuggable -- for lots of different flavors of learning.

I might roll a new algorithm. Just data, often a little puked-up version of some class I know from prod, only with two fields instead of 11, and one tree-level instead of nine.

I might use a new library, a very common case. "How do you put those three things together to make a roundtrip to the service?" "How do you turn off null-handling?" And so on.

I might go poking for an MRE of some bug. MRE means Minimum Runnable Example. I very often find bugs in my production code that inconvenient as hell to get to in my production code.

I get a suspicion: "Do you suppose the handle isn't being closed?" I write some code, not calling production at all, and leave the handle open, and see what happens. MRE's are important if you're gonna take a problem to stack overflow.

And there's one more for the geek-young: I *do* hope you are using the internet all the time as you program. Looking things up well is not only not a weakness in a geek but is actually a tremendous strength.

I can't tell you how many bugs I've fixed *without* using the production code during the investigation. It's a really important and underplayed technique.

Anyway, I'm gonna wrap this one. It's meandering, no moral, no slide, just a brain dump.

I use my testkit every day for things that aren't tests, aren't TDD, and aren't artifacts I keep.

Catcha later!