Exploring Extreme Programming
Last time (“Extracting” in References), we looked at why you’d use parameterized tests, to reduce duplication, improve clarity, and improve test quality. This time we’ll look at an example parameterized test in three languages: Java, Kotlin, and Swift. Java Example Continue reading Example Parameterized Tests: Java, Kotlin, and Swift
Duplication across tests may not be as harmful as duplication in production code, but a parameterized unit test can reduce duplication and help us create better tests. Judging Tests – The Pause Spotting duplication in tests is like spotting it Continue reading Extracting Parameterized Unit Tests
Conversations about user stories focus on the behavior of a system, without regard for time, memory, etc. Other times, we have real-world constraints – quality attributes – that may not fit comfortably as stories: performance, memory, extensibility, etc. Behaviors are Continue reading User Stories and Quality Attributes
Automated refactoring tools are great, but sometimes the tool doesn’t make the best choice. We can often nudge the tool to a better choice. Why Bother? Why bother nudging? Couldn’t you do the refactoring manually just as quickly? You could Continue reading Refactoring: Forcing the Right Extract Method
Nested structures are challenging to read; a pipeline is usually easier to read and think about. Nested structures have that “arrow of doom” feeling, where you work your way in multiple levels then out. It’s hard to tell what’s being Continue reading Nested Loops to Functional Pipeline
Sometimes you want to change from using a basic type (such as Int or String) to a type that contains the basic type as a value. (See Refactoring in the References.) The change itself isn’t hard, but then you have Continue reading Wrapping a Type, All the Way
I developed the INVEST model years ago to help someone (and then many people) think about the user stories they were creating. Is INVEST all you need to create good stories? Unfortunately, no. INVEST Briefly, INVEST (see References) is an Continue reading All You Need is INVEST? No!
Environments vary substantially between computers, so you’ll often see environment-specific code hidden in the PEEKs and POKEs of old BASIC programs. We’ll take a brief tour of the Ohio Scientific and Commodore 64, two computers from the late 1970s to Continue reading Ohio Scientific and Commodore 64 Environments
Once in a while, I run into a 1980s-era BASIC program, typically written for Commodore 64, Apple ][, or TRS-80. I’d like to transliterate it into a modern language, refactor it, and explore it. These old programs make a nice Continue reading Transliterating Old-School BASIC
When we’re creating or extending systems, there’s often one type of user that’s our main focus. We often have no trouble thinking up capabilities they need. But other types of users are often forgotten. We need to enlarge our view, Continue reading Forgotten Stories