Changing untested code, without breaking it

In general, Legacy Code was not designed to be testable. Putting the existing codebase into a test suite is a very challenging step.

Problem is: without tests, every code change is risky. How do you know if you broke something?

Let's see what can get in the way and how you can solve every obstacle. Let's put some automated tests on your codebase!

🎓 Related articles

• Work faster and safer on untested code with Overcommitting

  A technique you can resort to when you need to make risky changes.

• The best way to start testing untested code

  Should you write E2E tests to cover more cases faster? Or is there a better approach?

• 4 developers working their way through Legacy Code

  Practice working with code you've never seen before helps make it easier. Here's my selection of videos that will expose you to seasoned developers doing that!

• 7 techniques to regain control of your Legacy codebase

  Working with Legacy Code is no fun… unless you know how to approach it and get your changes done, safely.

• A quick way to add tests when code has database or HTTP calls

  You need to fix a bug, but you can't spend a week on it? Here's a technique to isolate problematic side-effects and write tests within minutes.

• The key points of Working Effectively with Legacy Code

  This book is a reference. Here's my summary of its salient points so you understand why it's so recommended.

• Use the Mikado Method to do safe changes in a complex codebase

  When a codebase is large and complex, it's risky to big changes. Here's a structured way to approach the problem.

• 3 steps to add tests on existing code when you have short deadlines

  Here's a recipe you can follow when you want to add tests on Legacy Code, but you don't have much time to do so.

Written by Nicolas Carlo who lives and works in Montreal, Canada 🍁
He founded the Software Crafters Montreal community which cares about building maintainable softwares.