Don’t Give Up on TDD Before Reaching the Breakthroughs
Dan Abramov recently tweeted:
TDD paralyzes me. I’m all for writing tests early in the process — especially in library code. But I can’t write them before I *play*. I need to write a shitty draft and play with the behavior to understand what I really want. Then rewrite guided by tests.
— Dan Abramov (@dan_abramov) January 19, 2019
That’s the beginning of a thread, so there’s more to it. But it gives me a chance to say to Dan, and the many folks who’ve shared this: You can still grow in Test-Driven Development. (Heck, I’m still growing.)
But instead of short tweets commenting on other short tweets, I thought I’d reply here. There’s room to discuss the gray areas.
Make a Mess to Clean a Mess: Refactoring, Continued
Refactoring is moving in small steps, with each step verified by unit tests. As I demonstrated last time, these steps are much smaller than most people are used to. Let’s continue the same example to learn some new things about refactoring.
Reading is not as good as doing. I learned from the folks at Big Nerd Ranch that our brains make important connections when we type code. Download my code and walk through the refactoring steps yourself.
Don't Lose Your “Flow”… Quickly Generate Test Code!
Subscribe to Download these FREE Code Snippets
Languages: Swift and Objective-C
IDEs: Xcode and AppCode
You’ll get our newsletter on Clean Code techniques for iOS developers. And you’ll get instant access to these code snippets!
We take your privacy seriously. See our privacy policy here.
When You Refactor, Are You Using Small Steps?
Refactoring remains a much-misunderstood discipline. Even when folks do have unit tests to back their changes, how long does the code stay broken? Let’s return to the idea that refactoring happens in very small steps.
No, even smaller than that.
Why Is Random Test Order a Big Deal for Test Quality?
Have you ever seen a unit test pass in isolation, but fail when run in a suite? Or vice versa, pass in a suite, but fail when run in isolation?
Besides the other improvements for test-centric workflows, Xcode 10 brings a rarity: a new XCTest feature for unit tests! Randomizing test order will help us flush out mistakes in the design of our tests.
Let’s start by examining a symptom… Have you ever seen naming like this in a test suite?
func test01RunThisTestFirst() { … }
func testCheckSomethingElse() { … }This is a dirty trick to get the top test to run first, before any other tests in the suite. It relies on the fact that currently, tests within a suite run in lexicographic order. 01 comes early in ASCII, so test01RunThisTestFirst will run first.
Joy! Xcode 10 Promises to Improve Test-Centric Workflows
Every WWDC, I hope for improvements to unit testing — but have learned to expect disappointment. So at WWDC 2018, I was surprised to have my low expectations thwarted! Xcode 10 brings changes that will improve my test-centric workflow.
For several years, Apple’s changes for test support have underwhelmed me. They focused on:
- Xcode Bots (…I tried them. I gave up.)
- Performance tests (…My code is not performance-critical.)
- UI tests (…I don’t write any.)
With Test-Driven Development, unit tests run locally are my primary tool. The features above may have helped some people, but I wasn’t one of them.
So what did WWDC 2018 bring me? Here’s what I see on the horizon with Xcode 10.
Do You Refactor without Tests? It’s Time for Safety
When you refactor, do you have unit tests covering you? …If not, why not? …If so, how do you know?
To me, it seems that the state of refactoring has gotten worse across the industry. Both managers and programmers and managers say the word “refactoring” more than ever. But they almost always mean, “I’m going to change a bunch of stuff. Then at the end, we need to make sure I didn’t break anything.”
But that’s not refactoring. That’s rewriting.
How to Improve Code Comments with Little Refactorings
Does your code have comments? Sometimes they’re helpful. But most of the time…
Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.
As Jeff Atwood explains, code tells you how, comments tell you why. A well-placed code comment is a level above the code itself, explaining why something is written the way it is. But! We can express most comments as code, using well-named identifiers. The Refactoring book calls this Introduce Explaining Variable. Martin Fowler has since renamed that refactoring to Extract Variable to help folks find it in their IDEs.
Code Smells: How Many Do You See in This Method?
It’s time for a quick exercise in code smells!
How many code smells do you see below?
The 3 Laws of TDD: Focus on One Thing at a Time
When I was first learning TDD, I’d try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was because the test code wasn’t right.
One of the tricky parts of TDD is that we’re creating two streams of code in parallel: the test code, and the production code. Two things changing at the same time… that’s a hard thing to keep in your head!
My Crazy Plans for the New Year (Book Teaser)
Happy new year! It seems like good time for a Quality Coding retrospective. I also want to share some goals for 2018.
…Did someone say, “Are you writing a book?”