TDD

My TDD Isn’t Judging Your Responsibility

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 calls it Stupid Busy, and I think that nails it pretty well. All you’re really saying is that you’re too busy to go faster. ~@GeePawHill […]

My TDD Isn’t Judging Your Responsibility See Full Post

Use Supplier Or Supplied Or Both?

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 with an interface like this: do( DataSource supplier ) And its body is basically the same as our starting chunk, but with a prolog that

Use Supplier Or Supplied Or Both? See Full Post

How To Test Depends On What To Test: Money, Chaining, And Steering

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 to enable us to ship more value faster. Deciding what is "value" is not a TDD task. The larger agility certainly asks us to make

How To Test Depends On What To Test: Money, Chaining, And Steering See Full Post

Avoid Implementation Inheritance: GeePaw Goes All Geek-y

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 will go further: I avoid, maybe not as much as the plague, but surely as much as the measles, even deriving any sub-class off of

Avoid Implementation Inheritance: GeePaw Goes All Geek-y See Full Post

TDD & The Geek-Young: Is Tdd Right For Noobs?

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 you’re geek-young, the great challenge is just to close out the primary case. Hell, you barely learned the syntax, you’re just learning the library-set. Just

TDD & The Geek-Young: Is Tdd Right For Noobs? See Full Post

The Rigorous Playpen

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 want to draw a box somewhere where there’s room in that picture, and I want to label it "rigorous". Let’s call it the rigorous playpen.

The Rigorous Playpen See Full Post

Sync Points Reduce Our Trade’s Effectiveness

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 the market and adjust the direction in which the project is headed. Second: the belief that no given team is able to do all the

Sync Points Reduce Our Trade’s Effectiveness See Full Post

What TDD Tests Prove

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 or your backend’s perspective, then test to the level of feeding it JSON. If u think it doesn’t work, then u need another library. Testing

What TDD Tests Prove See Full Post

Awkward and Graceful 2 (A Recovery)

This entry is part [part not set] of 2 in the series Awkward and Graceful

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, tho one the hardcore among us have to be dragged kicking and screaming towards. Don’t automate a test for it. Again, entirely legitimate, and actually

Awkward and Graceful 2 (A Recovery) See Full Post

Awkward and Graceful Collaborators

This entry is part [part not set] of 2 in the series Awkward and Graceful

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 larger labels on ever subsets. and at bottom, 100% of it is Von Neumann architecture code.) For the purposes of this conversation, I’ll be thinking

Awkward and Graceful Collaborators See Full Post

Scroll to Top