I've Test-Driven 100+ Legacy ABAP Programs & Here's What Actually Works

Last month, a senior developer gave me that familiar look of skepticism when I suggested we apply TDD to our legacy ABAP codebase.

"That sounds great in theory, but we've got 20-year-old code with no documentation and impossible deadlines. We don't have time for academic exercises."

I get it. I really do.

Eight years ago, I was making the same arguments. Our team was constantly firefighting production issues, our deployments were nerve-wracking multi-day affairs, and suggesting "let's take time to write tests" felt like bringing a book on swimming techniques to a sinking ship.

But after spending the past years gradually transforming legacy ABAP code across three major SAP implementations, I've discovered a practical approach that actually works in the real world - where deadlines exist, technical debt is overwhelming, and nobody has time for perfectionism.

The Real State of Legacy ABAP

If you're working with SAP, you're likely dealing with:

• Monolithic function modules with 1000+ lines of code
• Critical business logic buried in obscure includes
• Global variables changing unpredictably
• Code that nobody wants to touch because "it works somehow"

One of my clients told me about a 30,000-line program that handled their entire order processing workflow. Documentation consisted of sporadic comments like "// Added by John Doe - 2006 BC" and "ATTENTION: logic not completed: sometimes fails for European customers."

Sound familiar?

The Gradual Path to Testable ABAP

The breakthrough came when we stopped treating TDD as an all-or-nothing approach and instead developed a step-by-step methodology we now call the "Clean Legacy method":

1. Identify Critical Pain Points

We looked for modules that caused the most production issues and began there - not with the "cleanest" code that would be easiest to test. This created immediate business value and built credibility for our testing approach.

2. Create a Characterisation Test Harness

Before changing anything, we built tests that documented current behaviour - even the buggy parts. This gave us a safety net that would alert us if our changes affected existing functionality.

Key technique: We used the ABAP debugger to trace input/output behaviour before diving into the internal logic. This helped us identify the relevant interfaces and build from there.

3. Extract, Don't Rewrite

Instead of the massive rewrites that never get approved, we extracted small, testable functions from the existing codebase. Each extraction improved the code incrementally while preserving original behaviour.

4. Create Seams for Dependencies

We developed simple wrapper DAO classes around database calls and external systems, allowing us to test business logic independently of SAP infrastructure.

5. Gradually Expand Test Coverage

With each bug fix or feature addition, we expanded our test coverage - never trying to reach 100% all at once, but steadily improving over time.

Real Results: Beyond Theory

At my largest client, this approach led to:

• 42% reduction in production incidents over 8 months
• Deployment time reduced from average 2.5 days to 4 hours
• New developer onboarding shortened from 6 weeks to 3 weeks

The most surprising result? Developer satisfaction increased dramatically. The constant stress of "will this break something else?" diminished, and the team started taking pride in their increasingly clean codebase.

One developer told me, "I used to dread touching the tax module. Now I actually volunteer for those tickets."

Practical Implementation: The 10% Rule

We introduced what we call the "10% rule": Dedicate 10% of each sprint to improving testability. This small, consistent investment compounds over time, and it's much easier to get approval for than major refactoring projects.

The key insight was realising that you don't need permission to write tests - you need to demonstrate that tests save time rather than consume it.

What You Can Do Today

If you're drowning in legacy ABAP and want to start implementing this approach:

1. Select a single troublesome module that causes regular issues
2. Create a simple test class that documents its current inputs and outputs by writing test methods
3. Extract one piece of business logic into a separate, testable method
4. Run your test to ensure behaviour hasn't changed
5. Share your approach with one colleague to start building momentum

This gradual, practical approach has worked across dozens of SAP implementations of my clients - from manufacturing to retail to public sector.

What's the most challenging aspect of working with legacy ABAP code in your organisation?

And what small test might you write today to make your next change less stressful?

#ABAPDevelopment #LegacyCodeRefactoring #SAP #TestDrivenDevelopment #TechnicalDebtReduction

--

📌 ABAP devs are learning to write real unit tests, apply the test-first mindset, and refactor code with confidence - in just 3 days.

Ready to code without fear?

Join the free 3-Day TDD Challenge: https://www.martinjonen.com/tdd-3-day-challenge