TDD in Legacy Code Transformation
Legacy Code is a nightmare to maintain. Escape this by introducing TDD. I created the TDD in the Legacy Code series to help you achieve this step-by-step.
You tried TDD... but it didn’t work
TDD in Legacy Code seems impossible. The theory is simple: You read books, you watched courses, and you tried applying it to the legacy project in your job, but it didn't work. I made the TDD in Legacy Code series to help you introduce TDD step-by-step.
Why software engineers find it valuable
You don’t want to waste your time with trial-and-error on how to introduce TDD in Legacy Code. You also don’t want to risk your job reputation by making risky changes destabilizing the system. That’s why I made this series so that you can introduce TDD step-by-step in a safe way, without overwhelming the team, without stopping feature delivery, and keeping the system running in production the whole time.
✔ Step-by-step guide in introducing TDD to Legacy Code
✔ Applying the TDD transformation to Legacy Microservice Architecture
✔ Ask me questions about the challenges you face applying TDD in Legacy Code
The series outline above is a rough draft. As I write the articles, I may update the outline (and may take into account reader feedback and questions). This series is being released incrementally during the next several months, week-by-week.
What you’ll get out of this?
You tried reading TDD books and watching TDD courses, but none of them worked in practice because they showed simple demo projects, whereas, at work, you are dealing with a complex Legacy Project. The books and course didn’t show you how to introduce TDD in Legacy Code.
That’s why this TDD in Legacy Code Series will provide you with:
✔ Step-by-step guide in introducing TDD to Legacy Code
✔ Applying the TDD transformation to Legacy Microservice Architecture
✔ Ask me questions about challenges you face applying TDD in Legacy Code
FAQ
Who is this for?
This series is for Engineering Leaders and Senior Developers who are highly experienced, but they’ve been burnt by the maintenance of Legacy Code. They’re motivated to build quality software and want to practice TDD, but aren’t sure how to do it safely within their current project because it’s untestable. I’ll show you step-by-step on your personal project where you can practice on your own, and when you try it out on your real-life project, I’ll support you with any challenges that you face.
Who this is NOT for?
If you already work within a company that already practices TDD and Continuous Delivery, and has almost zero Regression Bugs, then this series is not for you.
About me
My name is Valentina Jemuović, I’m a Technical Coach at Optivem.
Thanks to my 23,000+ LinkedIn followers, I write posts about TDD, Hexagonal Architecture, and Clean Architecture.
As a Technical Coach, I’ve helped teams worldwide introduce TDD in Legacy Code, and now I want to help you achieve the same. By becoming a Premium Subscriber, you can learn step-by-step how to introduce TDD in Legacy Code and ask me questions if you need help along the way.
I've heard many developers say that they have integration and unit tests that span the entire system to check that it's working, so why would they need more tests?
I received an insight question on LinkedIn, from Daniel Steinberg https://www.linkedin.com/feed/update/urn%3Ali%3Aactivity%3A7265432517472645120/
"In my mind, TDD and Legacy Rescue are two separate workflows. Both involve test coverage and refactoring, and in both cases, refactoring is directed by the Four Rules of Simple Design (of which the first rule necessitates test coverage). The difference is in the end-goal of refactoring. In TDD we refactor relentlessly (or, in Kent Beck's words, mercilessly) until we cannot refactor anymore. In Legacy Rescue, by contrast, we follow Arlo Belshee's adage: "I don't want good. I want better ... fast."
Now, while doing Legacy Rescue, we will sometimes want to shift into the TDD workflow, particularly when we have successfully isolated our change point and are ready to implement new functionality. But by this point, we are no longer in Legacy Code.
Your thoughts?"