Have you ever had one of those “down-the-rabbit-hole” experiences, in which one idea sends you careening through a wormhole of thought? Such a journey often yields unexpected results, yet the “mind map” of your travels can actually be even more surprising. Well, it was one such “Eureka!” moment that convinced me of the parallels between the classic Hello, World! program and Test-Driven Development (TDD).
In my last blog post, I explained why metaphors are so important and how they can help raise our chops (and our hopes) when it comes to influencing the business side of things. The Seat Belt metaphor used in my previous example may have worked great for some, but not for others. Keeping a few different ones at the ready helps you adapt on-the-fly and better connect with whomever you’re speaking with. Another one of my favorite car metaphors to use is inspections.
One of the most mundane and frightening tasks for many developers is writing integration tests. It's a time-consuming, fragile, and often difficult and frustrating task to accomplish. What makes it even worse is that it quickly gets out of hand and breaks often, which leads to frustration and dropping the idea completely.
Code refactoring, as defined by Wikipedia, is “the process of restructuring existing computer code — changing the factoring — without changing its external behavior.” As such, refactored code should introduce no behavior changes. Otherwise, you're not refactoring. You're refactoring and doing something else.
First, a confession: I recently wrote a blog post about unit testing an Angular application. Well, as it turns out, what I was in fact doing was trying to convince everybody of the joys of Angular testing. Including myself.
I was looking for inspiration for my next blog topic and read through some of my old posts. I came across one called “Confidence From Your Code” that originally appeared on Femgineer in 2014. I thought: “Perfect! It's been a few years since I wrote that, I now work with Corgibytes and have even more legacy code experience, I'll update my thoughts.”
Do you ever refactor your test code? If not, I hope you consider making this part of your normal practice. Test code is still code and should adhere to the same high standards as the code that's running directly in production. As important as it is, refactoring your test code is actually a little risky. It's very likely that you could turn a perfectly valid test into one that always passes, regardless of whether or not the code that it covers is correct. Let's explore a technique for protecting against that possibility.
Integration tests? Unit tests? Acceptance tests? How do all these tests work together and what should you focus on first? We like to think of testing as a pyramid. The goal is to build an entire pyramid and keep it growing at scale.