Importance of Passing Tests When Refactoring Code

Agentic AI is starting to change how we build software. Most conversations today are still focused on speed—how quickly code can now be generated. But that may not be the most important shift. 𝐖𝐡𝐞𝐧 𝐀𝐈 𝐬𝐭𝐚𝐫𝐭𝐬 𝐰𝐫𝐢𝐭𝐢𝐧𝐠 𝐚𝐧𝐝 𝐦𝐨𝐝𝐢𝐟𝐲𝐢𝐧𝐠 𝐜𝐨𝐝𝐞, 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐧𝐞𝐬𝐬 𝐛𝐞𝐜𝐨𝐦𝐞𝐬 𝐭𝐡𝐞 𝐫𝐞𝐚𝐥 𝐜𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞, 𝐧𝐨𝐭 𝐬𝐩𝐞𝐞𝐝. Take a simple banking example. You’re building a system to monitor lending KPIs—delinquencies, exposure limits, early warning signals. Earlier, experienced engineers would carefully design and implement this. Now, with agentic AI, much of this can be handled by agents: Generating pipelines, writing validation logic, Adjusting thresholds, Even refining rules over time. It’s powerful. But it also introduces a different kind of risk. Because small deviations can have large consequences. What happens if: A KPI definition is slightly misunderstood? A threshold gets tweaked during a refactor? An edge case quietly breaks after an optimization? In a banking context, these aren’t just bugs. They can become real risk events. This is where 𝑻𝒆𝒔𝒕-𝑫𝒓𝒊𝒗𝒆𝒏 𝑫𝒆𝒗𝒆𝒍𝒐𝒑𝒎𝒆𝒏𝒕 (𝑻𝑫𝑫) starts to feel less like a best practice and more like a control mechanism for AI-driven systems. Based on experience working with such systems, its role is evolving: 1. 𝐂𝐨𝐝𝐞 𝐢𝐬 𝐧𝐨 𝐥𝐨𝐧𝐠𝐞𝐫 𝐬𝐭𝐚𝐭𝐢𝐜 Agents keep changing it. Tests ensure it stays correct over time. 2. 𝐓𝐞𝐬𝐭𝐬 𝐛𝐞𝐜𝐨𝐦𝐞 𝐭𝐡𝐞 𝐫𝐞𝐚𝐥 𝐬𝐩𝐞𝐜𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧 AI may misinterpret documents—but it responds reliably to tests. 3. 𝐑𝐞𝐟𝐚𝐜𝐭𝐨𝐫𝐢𝐧𝐠 𝐧𝐞𝐞𝐝𝐬 𝐠𝐮𝐚𝐫𝐝𝐫𝐚𝐢𝐥𝐬 Agents can optimize code, but within clearly defined boundaries. 4. 𝐄𝐧𝐚𝐛𝐥𝐞𝐬 𝐬𝐞𝐥𝐟-𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐢𝐨𝐧 Detect → fix → validate loops only work if tests exist. 5. 𝐇𝐞𝐥𝐩𝐬 𝐜𝐨𝐧𝐭𝐫𝐨𝐥 𝐡𝐚𝐥𝐥𝐮𝐜𝐢𝐧𝐚𝐭𝐢𝐨𝐧𝐬 Logic that “looks right” but isn’t gets caught early. 6. 𝐊𝐞𝐞𝐩𝐬 𝐦𝐮𝐥𝐭𝐢𝐩𝐥𝐞 𝐚𝐠𝐞𝐧𝐭𝐬 𝐚𝐥𝐢𝐠𝐧𝐞𝐝 Tests act as a shared contract across components. 7. 𝐒𝐮𝐫𝐩𝐫𝐢𝐬𝐢𝐧𝐠𝐥𝐲, 𝐢𝐭 𝐬𝐩𝐞𝐞𝐝𝐬 𝐭𝐡𝐢𝐧𝐠𝐬 𝐮𝐩 Define correctness once → let agents iterate rapidly within safe limits. The shift is quite fundamental: 𝐄𝐚𝐫𝐥𝐢𝐞𝐫: Code → tested for correctness 𝐍𝐨𝐰: Tests → define correctness → code is generated to satisfy it In this new world, tests are not just validating the system… they are guiding it. Curious how others are thinking about testing as agentic systems move from experimentation to production. #AgenticAI #AIEngineering #GenerativeAI #BankingTech #SoftwareEngineering #TDD

“You know what’s scarier than a failing test? A passing one that shouldn’t.” A while back, I revisited a feature I had shipped.  It worked. It passed the tests. It met the deadline. But when I came back to it? The logic was fragile. The tests were shallow. And every change felt like playing whack-a-bug. So I rewrote the test suite. Covered edge cases I hadn’t considered the first time Made failures obvious, not cryptic Focused on clarity and resilience, not just speed It took time—but it paid off. Now the code is easier to maintain, easier to trust, and less of a time bomb. Great software isn’t just written—it’s tested, broken, rewritten, and tested again. What’s your approach to testing smarter, not harder? #SoftwareTesting #CleanCode #EngineeringExcellence #TestCoverage #Refactoring #SoftwareDevelopment #TechDebt #TestingCulture

AI can write your code — but only a test-first mindset keeps it from breaking ⚙️ After 2.5 years of hands-on AI coding, one thing is obvious: you can’t skip designing and automating your tests when working on complex code. AI makes writing and refactoring code fast — but if you don’t start with acceptance tests, you’re just automating chaos. My learnings: 💡 Think test-first. Define your acceptance criteria and evals before generating or refactoring code. Sometimes it takes creativity to figure out how to test things, but the effort always pays off. 🚫 Don’t generate tests from your existing code — they’ll just repeat its bugs. If your code says 2+2=6, the test will “prove” it’s correct. ✅ Instead, generate them from your PRDs or requirements, then apply them to the code. Keep a compact PRD in your repo and use it as context for the AI — with use cases, edge conditions, and examples. 🤖 Use AI to automate regression, performance, and stress tests — but always review what it writes. Would love to learn more from your experiences.

People tend to believe that there is more of a trade-off between Quality and Speed than there really is. Most of the time, if you’re doing a good job of refactoring and writing tests as you go, the final product doesn’t take any longer than it would have to do it “the hacky way,” if by “the final product” we mean “a system that actually works and does what its users need.” True, once in a while there are huge problems that you can’t tackle right now. For example, maybe the right thing to do is to redesign your application with a whole new data store, but that could take years. You can’t do it right now. That said, _most_ of the problems that users experience with software don’t come from these decisions to set aside these huge projects for later. Most issues come from a series of small decisions that grew over time into a complexity that nobody understood or managed correctly. Often they come from a developer just _feeling_ rushed, like they can’t refactor this right now, they can’t test this right now, etc., when really they do have the time to do it. Let me give a specific example. I once caused a fairly significant production outage at YouTube. I was mid refactoring a very complex piece of code, and I had not written a test at the highest level to make sure all the pieces still worked well together. Had I written the test, the issue absolutely would have been caught. So egg on my face, right? Well, there are two lessons to take away from this, actually: 1. The shallowest lesson here is that one should have tests that cover what one is refactoring. 2. A deeper lesson is this: the function I was refactoring had grown incrementally into a hairball that was basically impossible to understand. Every person who had worked on it (many people) had chosen _not_ to fix its structure over a period of many years. They also had never written a test for its behavior—you couldn’t even look at a test to understand what it was _supposed_ to do. The function was basically Pandora’s Box; some day somebody was going to touch it and cause something to break, and the person who did that happened to be me, because I wrote about 100 changes to it (incremental refactorings) and one of them happened to have a bug. So should I have written a test? Maybe. Honestly, until I went through the process of refactoring it, it was really hard to tell what it was _supposed_ to do in all sorts of various edge cases that it covered. Am I personally responsible for that outage? Of course! But am I the _only_ person who contributed to that outage occurring? No. Every time somebody says, “well, I’ll refactor that later,” and doesn’t, “we really ought to have monitoring eventually,” “I should write some tests some day,” THAT is where most problems start. And the wild thing is—almost always, those problems didn’t have to start! If everybody had maintained the system well as they went, it’s unlikely there would have been any impact to the speed of delivery.

Tests aren’t for bugs. They’re for speed. Let me explain. Bug-free code is fiction. But fast, fearless iteration? That’s real. And that’s what tests are for. A solid test suite does 3 things: 1- Breaks when you break stuff. 2- Explains behavior better than your comments. 3- Gives you the guts to move fast. If touching code feels dangerous, you don’t have enough tests, or the right ones. Tests aren’t extra. You don’t write them to please a manager. You write them so you can refactor without flinching. Speed is profit. Tests make speed safe.

Most developers are trapped in the Legacy Code Fear Cycle: ❌ No tests = fear of breaking things ❌ Fear of breaking things = no refactoring ❌ No refactoring = code gets worse ❌ Worse code = more fear Just coached a developer through breaking this cycle. The breakthrough? Approval testing as a safety net. Instead of writing perfect unit tests first: ✅ Capture current behavior with approval tests ✅ Refactor with confidence ✅ Replace with proper unit tests gradually Key insight: Don't test what the code SHOULD do. Test what it ACTUALLY does first. They went from "paralyzed by legacy code" to confidently refactoring in one session. Your legacy codebase doesn't have to stay scary forever. If your team is stuck in the fear cycle, let's break it together. DM me and I'll share the exact approval testing framework that got this client unstuck.

Sometimes, we have code that works but has problems. Maybe it is too complicated. Maybe it has methods that are too long and do too many things. Or maybe it is hard to read because things are named badly. In any of these cases, the answer is to refactor the code. Refactoring is defined as “restructuring existing source code to improve its design, structure, and implementation without changing its external behavior or functionality.” Usually, this involves making a series of small changes that gradually improve the code. Before you start any refactoring, you need to make sure you have unit tests that verify the external functionality you need to preserve. A broken test means you need to roll back the change and try again. If you don’t have adequate tests, write them before you start. What if you don’t have tests, and the code is so badly structured that you can’t write them? In that case, you can look at Michael Feathers’ great book, “Working Effectively With Legacy Code” (https://lnkd.in/gCSvihYP). Feathers defines legacy code as any code without unit tests. This book has a lot of techniques for relatively safe refactorings that get the code into a state where you can write tests. Refactoring steps don’t need to be huge. In fact, it is better if they are not. If you make a small change, it is easier to roll back if you break something. Then you can make the next small change. Very often, a refactoring step may seem to make the code woaxrse, but that is okay. It’s like rearranging the furniture in a room by moving one piece at a time. In the middle of the process, you might be able to sit in the chairs, but the room would look messy. Possibilities for useful refactorings are endless. Maybe you find a variable name that is confusing. Then you can improve things by renaming it. Perhaps you find a confusing method, and can break out part of it into a well-named smaller method. You might extract or inline a variable. At a larger scale, you might want to extract an interface or a superclass, or move a function from one class to another, or into its own class. I will try to delve into some of these more deeply. In the meantime, Martin Fowler’s “Refactoring: Improving the Design of Existing Code” is the seminal resource. (https://lnkd.in/gVe6tDFm).