TDD

Detail: Not The Long Game

I was gratified by the response to my first "detail" article. But I did note that many persons praised my article for its commitment to the long game. Framing the commitment, for a geek, to detail, as a long game, seems right, sounds right, cuz after all, we only ever care about quality in the long game. And this is why y’all can’t convince anyone to do this or think this or feel this. When does a bad variable name […]

Detail: Not The Long Game See Full Post

Detail: Series Intro

Detail: The thing that strikes me over and over again, in my own work style, in my Friday group’s analytics, in Ron’s long-running Kotlin and short-running Gilded Rose series, is how much attention high-skill geeks pay to some of the smallest details in the code. An example. I was doing Gilded Rose the other day, first time in years, and we start with the ugly method, which we’re asked to add a feature to, following certain constraint rules to make

Detail: Series Intro See Full Post

TDD Pro-Tip: Against Automated Macrotests

TDD Pro-Tip: I advocate against automated macro-tests — those whose base is entire running programs –, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I’m calling macro-tests, so let’s poke around a little. The central idea of "macro-test" is that we write code that launches an entire subject program and probes its behavior "from the outside". There are often multiple programs in

TDD Pro-Tip: Against Automated Macrotests See Full Post

Some TDD History

I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek. I believe there are several related factors in play, ranging in abstraction level from pressures of global ieconmics to mistakes in local human interaction. Studying this large-scale failure, even while having some small-scale successes, underlies much of my work on change. Because, while the overall

Some TDD History See Full Post

On Over-Coding

Let’s talk for a minute about "over-coding". Over-coding, when you’re a TDD’ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to non TDD’ers and TDD’ers alike. Many people, pro-TDD and con- both, seem to think of TDD as the name for a collection or rigorous mechanical rules. TDD is a kind of jack-in-the-box, where you sit there and turn the handle, circle circle circle, and out pops

On Over-Coding See Full Post

Me, Gary, and TDD

True story: Eighteen or so years ago, I had a gig rolling code at an engineering company. We were writing a windows app using Microsoft Foundation Classes to drive a TTY interface to a box of various radio hardware junk. I was gigged in by a guy I’d taught a c;ass (in MFC) to, because he liked that I knew my shit, and he loved that I spoke openly about joy, right in the classroom. right in front of God

Me, Gary, and TDD See Full Post

Ten I-Statements About Refactoring

HOT TIP: Ted Young’s "Make Your Code More Testable" class is coming up August 23rd. The class is excellent (and covers much of what I talk about below), Ted is a wonderful teacher – and I scored you a discount code. Go to MakeTestable.com and use code GEEPAW when you sign up to get $75 off! In the spirit of my Ten I-Statements about TDD, here’s ten more, this time about refactoring. I’m not covering everything, just hitting some of

Ten I-Statements About Refactoring See Full Post

Ten I-Statements About TDD

HOT TIP: Ted Young’s "Make Your Code More Testable" class is coming up August 23rd. The class is excellent (and covers much of what I talk about below), Ted is a wonderful teacher – and I scored you a discount code. Go to MakeTestable.com and use code GEEPAW when you sign up to get $75 off! Folks, I see a lot of ideas and opinions about TDD fly around, passed off as holy writ. By way of counter, I offer

Ten I-Statements About TDD See Full Post

On (Not) Using Mocking Frameworks

I’m long past on record that I think the use of auto-mockers outside of legacy rescue situations is bad policy. First, it’s easy to write "psuedo-tests" using an automocker. Psuedo-tests are tests that appear to prove things about your code that they don’t actually prove. Now, note, I’m not saying auto-mockers force one to write psuedo-tests. They don’t. But they do make it awfully easy. How? The combination of "don’t care" arguments in mocked method specs with hardwired returns makes

On (Not) Using Mocking Frameworks See Full Post

The UI Monolith Making App

The ultimate making app for a shipping multi-service system is actually a one-machine monolith with a UI. If your team is experiencing the most common pains from working in a large SOA environment, the productivity payback will be enormous. It’s important for me to take a second to remind you that there’s much more to this world than geekery. Please keep working for change all around you, including, especially, outside the monitor. Stay safe, stay strong, stay angry, stay kind.

The UI Monolith Making App See Full Post

Scroll to Top