We all have stories where automated tests could’ve saved us from disaster, but I
want to tell you a story of a time when I went overboard with a certain testing
practice and it went really badly for me…
This was a few years ago. I was working on
angular-formly and I had just
discovered React’s PropTypes feature. I thought it was the coolest thing since
sliced bread. lol, I just looked it up and
my first issue on the React
repo was asking if we could add an objectWith PropType validator. I wrote the
whole thing including tests and put that in the issue. Sophie Alpert responded
with:
Isn’t this what React.PropTypes.shape is for?
Ha! Whoops! Anyway, I decided it’d be really cool to have development-only
runtime validation on the configuration object that people pass to
angular-formly when configuring their forms.
My second issue on the React
repo was asking if the React team would be willing to extract prop types into
its own package (this has actually now taken place! Checkout
prop-types). That didn’t work out, so I decided to
write my own package and thus
api-check was born!
One of the cool things about a library like this is that the whole thing is a
bunch of pure functions! And we all know that pure functions are super easy to
test, right?! Also, because I had a very clear picture of what I wanted to
implement (with prop-types as my inspiration) I thought test-driven development
would be a synch.
So I set to work. I started writing a bunch of tests and implemented api-check
as I went. Honestly, it was exhilarating. (I’d say intoxicating, but I’ve never
actually had a drop of alcohol in my life, so I wouldn’t know 😅). I was having
a blast writing this out.
But as time went on, I started noticing something… It was becoming
progressively less fun and more difficult to implement the behaviors as I added
them. The library code started getting really complicated. Now I shudder even
thinking about it. There’s no way you could convince me to work on that code
anymore.
So what went wrong? I thought TDD was the process by which you create
beautifully and intentionally designed software. But what I was left with is a
mess that I don’t want to touch. I must have done something wrong…
I did. TDD is a three-step process. It’s often referred to as the “red, green,
refactor cycle”
Here’s the way it works:
- 🚨 Red: Write a test for the function/module you’re going to create before
it exists/supports the feature you’re adding. This gives you a test that fails
(you get a “red” error message). - ✅ Green: Implement just enough code to get that test passing (you get a
“green” success message). - 🌀 Refactor: Look over the code you have written and refactor it to ensure
it’s well-written, as easy as possible to read/understand, and well-designed.
(The cool thing with this step is that you now have a test in place that will
tell you if you break something as you refactor). - 🔁 Repeat: It’s a cycle, after all 😉 Keep going until you’ve finished
implementing everything you need to.
So where did I go wrong with api-check? Well, I kinda skipped the refactor step.
I got so excited from the “high” (another thing of which I’m ignorant) that I
felt from turning that red test to a green test that I just continued on with
the next feature without stopping to consider if what I was building was at all
maintainable. Turns out it wasn’t. I was building a monstrosity of
difficult-to-understand code. The code was legacy the second it left my fingers.
Conclusion
So, what do we learn from this? Test-driven development is awesome, and it can
really help you develop great code in certain situations. But if you skip the
refactor step and aren’t intentional about what you’re building, it can lead to
disaster.
Be careful out there, friends. And learn to use TDD the right way with me at
TestingJavaScript.com
🏆
Source link
