TDD in legacy code

How do we escape the “vicious cycle” of legacy code?

We have no tests (or have poor tests). Any change is risky and needs manual testing. We’re rushing to meet delivery deadlines - producing code, but there’s no time for tests.

Legacy codebases are expensive to maintain because:

• Unit tests are missing. Consequently, developers have to debug the code to verify it works correctly - this is a manual time-consuming process.
• Unit Tests are ineffective. The tests are not protecting against regression bugs and are hard to read, so developers have to spend a lot of time maintaining tests.
• Source Code is unmaintainable. The source code is a “big ball of mud”, low modularity, high cyclomatic complexity, so developers have to spend a lot of time reading and understanding existing code in order to make changes.

At some point, company leadership decides to introduce Unit Tests (and TDD). They hire some trainers to deliver some 2-5 day training about Unit Testing & TDD across all the developers.

Leadership expects that after this delivery will be faster and bug count will decrease.

But that does NOT happen!

Actually, the opposite happens - slower delivery and more bugs. It’s a disaster! The developers also lose motivation and say “TDD doesn’t work”.

During this webinar, we’ll discuss how to actually introduce TDD successfully.

The transformation requires transitioning towards testable architecture, writing effective tests and refactoring code, in a test-last approach. After these foundations, we can start the adoption of TDD.