Many software teams struggle with testing and verification of their code. There seems to be general confusion or misunderstanding around topics like unit testing, integration testing, functional testing, exploratory testing, test-driven development, test automation, and refactoring. When technical coaches introduce concepts like “levels” of executable checks, “testing strategies,” and the distinction between testing and checking, I notice many team members’ eyes glaze over. When the coaches show people how to write executable unit tests or how to do test-driven development, it seems as if they learn the mechanics in a rote way yet still aren’t sure where the various pieces fit into the bigger picture of effective software delivery. And they can’t easily judge which of the numerous topics may apply to their own workflow.
Continue reading A Broad and Shallow Introduction to Unit TestingCategory: Uncategorized
Template-Based Development Then and Now
There’s an old saying: There’s nothing new under the sun. Maybe there’s something to it. Details change, but the general patterns of things remain consistent. The wheel keeps turning, and if you live long enough you see the same spokes come around again and again.
James Shore, a well-respected figure in the software development field and the author of the highly-regarded book, The Art of Agile Development, has developed an approach to software development he has called a pattern language for testing without mocks.
I struggled to get started using James’ pattern language. Initially, I was trying to write code in two different ways in parallel – one using mocks and the other using the pattern language. I thought it would be interesting to apply the patterns to different types of languages and different programming problems. It was extremely frustrating. It seemed no matter what I did, I was breaking one of more of the “rules.”
Fortunately, James was willing to help me quite a lot, pointing out where I had gone astray and suggesting reference material to help me learn. He mentioned that people who have internalized testing with mocks often have similar difficulties picking up this approach, and that it requires a mindset shift.
That’s exactly what I was doing. I was approaching it from the perspective of testing with mocks and then seeing what would have to change to build the same solution using the pattern language. It proved to be a fool’s errand.
I paused and took a couple of days off from it. Then I read through all the material describing the various patterns and so forth. It struck me that what he was describing was very similar to the way we used to apply common application patterns in the 1970s-80s. By focusing on the comparison between “using mocks” and “not using mocks” I was missing the point.
Continue reading Template-Based Development Then and NowA conversation with my rubber duck concerning the linearity of time and other impossible things, plus a little about test-driven development and refactoring
Sometimes talking through a problem with a rubber duck can yield surprising insights.
With increasing frequency, I’ve been hearing comments to the effect that when people refactor code, they break existing test cases that were passing before they refactored.
When I ask whether the test cases “know” about underlying implementation details in the code under test, they look puzzled. Well, of course. How else would you know the code was working?
Hmm.
So, when I ask them whether they test-drive the refactorings, they look puzzled. Well, of course. We always test drive code changes.
Hmm.
So, when I ask them whether the tests break due to refactoring, even when the refactorings are test-driven, they look puzzled. Well, of course. That’s what we said, isn’t it?
Hmm.
I didn’t see how the last two statements could be true at the same time. I needed advice from my rubber duck.
Induced Work
People say there are certain things that are hard to unsee once you’ve seen them. When you start to see software development and delivery processes through the lens of lean thinking, it seems you can never unsee it again. You can’t fail to notice opportunities for improvement. Sometimes it’s puzzling that others don’t see the same things, but it may be they’re looking at the situation through a different lens.
Continue reading Induced WorkMy personal quest for a UML diagramming tool
Guest post by A. Cranky, Old Man
tl;dr – I’m using Visual Paradigm.
When I needed a way to create a reasonably good-looking sequence diagram for a recent engagement, I was suprised to discover more than 80 diagramming tools on the market. Given such a large pool of candidates, I expected to find several good ones, and I embarked on my quest in hight spirits.
You’d think at my age I would know better.
Continue reading My personal quest for a UML diagramming toolPoor Misunderstood COBOL
I stumbled across an article about COBOL dating from 2020, and I thought it might be useful to clarify a few points. The article is What Is COBOL and Why Is It in Demand? by Jennifer Seaton, published on the Make Use Of site.
Where to Find Prominent Voices in Software Other Than Twitter
Where to Find Prominent Voices in Software Other Than Twitter
Updated 6 Nov 22
Thousands of thoughtful and experienced software professionals use Twitter to share information and interact with one another. We’ve come to depend on Twitter as a source of information and interaction with colleagues.
With the recent changes at Twitter, many users are looking for alternative social media platforms. But many of us hesitate to “leave” Twitter because that’s where we find industry leaders in the software field, and we don’t want to miss out on what they have to teach us.
Continue reading Where to Find Prominent Voices in Software Other Than Twitter
Ten Landing Pages in Five Minutes
Way back in October, 2022, Florin Pop tweeted this question:
He got 400 responses in 10 hours. Some were lighthearted: “I would use HTML.” Others went into some detail about a favorite webapp development stack. I came to the party late, but I thought it would be a fun thing to try.
How we think about recruiting
There’s an odd situation in the software industry. Employers are adamant that they can’t find suitable talent to fill the technical jobs they have. Job candidates are adamant that they can’t find suitable work. It seems strange to me that both these things are true at the same time.
Many people have opinions and observations about this. Often, they cite academic studies, industry surveys, formal management models, psychology, and various other things that are confusing for a Bear of Very Little Brain like me. I wonder if we could go a long way toward solving this problem if we ajusted, just slightly, the way we think about what we’re aiming to accomplish, on the hiring side and on the job search side.
Scrum in quotes
William van den Ende was trying to find a good balance for quotes included in blog posts, and his effort inspired me to try and assemble a blog post entirely out of other people’s quotes.
It’s a bad idea. Set your expectations accordingly. Here goes.
Continue reading Scrum in quotes