An old blog of mine, We’re In This For The Money, recently got some attention, delighting me, of course. A full h/t to Jim Speaker @jspeaker for that! He quoted me thus: Too busy to #TDD? Too busy to pair? Too busy to #refactor? Too busy to micro-test? I call bullshit. My buddy Erik Meade […]
My TDD Isn’t Judging Your Responsibility Read More »
A coding pattern; replace supplied data with a supplier or a supplier with the supplied data. It is very common to create code with an interface like this: do( Data supplied ) We then use the data somehow to perform our functionality, whatever a do(…) method does. On the other hand, sometimes we create code
Use Supplier Or Supplied Or Both? Read More »
To have a serious conversation about how to test, we have to start by considering what to test. As a microtesting TDD’er, what I want to test is our logic. Enter the Money Premise The money premise of TDD reminds us we’re in this for the money, that is, the primary purpose of TDD is
How To Test Depends On What To Test: Money, Chaining, And Steering Read More »
So, day off before travel before onsite, playing ONI, having fun, but I want to muse about a highly geeky matter anyway… Do you ever override in a sub-class a method that’s already implemented in a super-class? I want to recommend to you a policy of avoiding that like the plague, whenever you can. I
Avoid Implementation Inheritance: GeePaw Goes All Geek-y Read More »
Possible causal point for a failure to value TDD: geeks thinking the main source of bugs in professional software is not handling the main case successfully. In any feature in any app, there are one or more primary cases. A given story is likely to be concerned with one of these at a time. When
TDD & The Geek-Young: Is Tdd Right For Noobs? Read More »
I’m bettin’ u already got some code. If yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a lot of code. In your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of "our code". I
The Rigorous Playpen Read More »
Companies spend a great deal of time and energy seeking to get their teams synchronized. Several forces motivate these efforts. It’s worth taking a second to look at these. One force: the belief that synchronization provides steering points. The notion here is that since we’ve just synchronized, now is a good time to react to
Sync Points Reduce Our Trade’s Effectiveness Read More »
If u think the semaphore mechanism in your library works, then test to the level of setting the semaphore. If u think it doesn’t work, then u need another library or o/s. Testing across threads is for people who are testing semaphores. If u think that your JSON transport works — from your UI’s perspective
What TDD Tests Prove Read More »
Continuing last night’s wobbly muse on graceful and awkward collaborators… In the light of day, I think I see four possible responses to the situation when your new code depends on an awkward collaborator or collaboration: Ignore it (possibly just for now). Write your test anyway and suffer the expense. This is a legitimate judgment,
Awkward and Graceful 2 (A Recovery) Read More »
Software Programs can be understood as (potentially huge) orchestras playing in concert. Depending on your level of abstraction, you might imagine systems, subsystems, layers, packages, objects, or even functions as the individual players. (Aside: Folks often make major distinctions in these abstractions, but to my touch, they feel all the same thing, just with ever
Awkward and Graceful Collaborators Read More »
