The other day, GeePaw Hill mentioned on Mastodon
“inline-jiggle-extract” is a coding pattern that needs describing.
If I were a better person, I would write that up.
As it happened, I’d recently talked about that pattern on LinkedIn
I found the sequence of inline, re-order statements, extract to be one of my favorite refactoring arpeggios.
It’s been awhile since I’ve done much coding. That’s not my day job anymore, and I lose interest working by myself. In the past week, however, I’ve had a couple opportunities to mob program remotely with the Canton Coders. With the COVID-19 restrictions on gathering in person, people are much more likely to work with you virtually.
So last week I found myself mobbing on the Roman Numeral kata and today on the Zeckendorf kata, both on cyber-dojo. A lot of fun was had by all, and I rediscovered what I know about Test Driven Development with a bit more clarity.
Josh Kerievsky called me to task for not following up on his third version of his story of providing a quick fix before a test-driven fix. As I said, I don’t want to be critical of Josh. I will, however, cast a critical eye on the code he has shared.
For those just tuning in, the previous installment talked about differences between the culture we espouse and the culture we practice. This installment will return to that.
The background for this post: Gil Zilberfeld posted a link to a blog post by Joshua Kerievsky. I had some questions and Josh’s response, to me, seemed to change the story a bit. As I suspected, the story is hypothetical, and changes to support the intended conclusion. This always makes it very slippery to talk about a story. The details matter. And in this case, the change overwrites the original, without any indication of what has changed. That makes it even harder to have a conversation about it.
I’ll give a synopsis of the story here, since it may change again. In brief,
- “A customer reports a defect. It’s inhibiting them from getting some important work done.”
- David finds the defect and test-drives a fix, including refactoring to re-design the code around the defect. He spends two hours doing so.
- In a parallel universe, Sally finds the same defect, fixes it without an automated test, hand-tests the fix, pronounces it good and pushes it to production. There’s no indication of how long this took, but presumably it’s intended to be less than two hours.
Should your tests mock outside services or not? I keep seeing discussions on this topic. On the one hand, it lets your tests be in control of the testing context. Otherwise it may be very difficult to create a reliable automated test.
- The external service might return different results at different times.
- The external service might be slow to respond.
- Using the external service might require running the test in a particular environment.
- It may be impossible to generate certain error conditions with the real service.
- There may be side-effects of using the real service.
On the other hand, our mock of the external service might differ from it in important ways.
- Our mock service might have a slightly different interface than the real one.
- Our mock service might accept slightly different parameters than the real one.
- Our mock service might return slightly different results than the real one.
- The real service might change behavior, and we won’t notice until we deploy to production.
This leaves us in a quandary. What to do? Read More
An open letter to a programmer who thinks that code coverage by integration tests eliminates the need for unit tests. Read More
Thanks to Tim Ottinger for reminding me of Arlo Belshee’s post, “Is Pair Programming for Me?” Go read Arlo’s post, as it’s insightful and has more useful content than most articles on pairing. I’m just going to springboard off of one skill that Arlo mentioned being important to learn.
How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.
A few years back, I took a course in “Beginning Improv Acting.” Read More
I saw that Alistair Cockburn had written a post about Seb Rose’s post on the Diamond Kata. I only read the beginning of both of those because I recognized the problem that Seb described with the “Gorilla” approach that, upon reaching the ‘C’ case.
“The code is now screaming for us to refactor it, but to keep all the tests passing most people try to solve the entire problem at once. That’s hard, because we’ll need to cope with multiple lines, varying indentation, and repeated characters with a varying number of spaces between them.”
I’ve run into such situations before, and it’s always be a clue for me to back up and work in smaller steps. Seb describes that the ‘B’ case, “easy enough to get this to pass by hardcoding the result.” Alistair describes the strategy as “shuffle around a bit” for the ‘B’ case. I’m not sure what “shuffling around a bit” means and I don’t think it would be particularly easy to get both ‘A’ and ‘B’ cases working with constants and not heading down a silly “
if (letter == 'A') "¦ elseif (letter == 'B') "¦” implementation. I was curious how I would approach it, and decided to try. (Ron Jeffries also wrote a post on the topic.) I didn’t read any of these three solutions before implementing my own, just so I could see what I would do. Read More
I was reading Laurent Bossavit’s book, “The Leprechauns of Software Engineering—How folklore turns into fact and what to do about it,” and came across his mention of “Comparing the Defect Reduction Benefits of Code Inspection and Test-Driven Development” by Jerod W. Wilkerson, Jay F. Nunamaker, & Rick Mercer. This struck me as an odd thing to study. Not only is Test-Driven Development not primarily about defect reduction, but the populations of defects it might reduce are likely to be very different from population of defects reduced by code inspection.
I then took a look at my own list of TDD studies and noted that most of these studies were focused on external quality as measured by absence of known defects, and time it took to develop the functionality. Keith Braithwaite, at Agile 2007, reported on internal quality, specifically Cyclomatic Complexity.
Quality and productivity are, of course, important things. And they’re easy to sell to some managers. Who could be against them? And I certainly wouldn’t continue to practice Test-Driven Development if it added defects or took a significantly longer time to create functionality. But that’s not why I practice TDD. Read More
I’ve achieved some notoriety with my Test Driven Development hat. Not so much when I wear it, but certainly when Uncle Bob does. So much so that he has received queries about acquiring or making them. Read More