TDD @ Erste Digital - "From 0 tests to TDD" (Nik Sumeiko)

Nik Sumeiko shares his success story - starting with zero tests and reaching TDD at Erste Digital.

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

---

Nik Sumeiko, Software Engineer & Architect at Erste Digital, in Vienna, shared his success story towards TDD:

Lesson #1: Be the person who initiates change

When Nik joined Erste, there wasn’t much interest in modernization - as he wrote, they weren’t interested in adopting Typescript inside React. This is an example of resistance to any change, not just TDD.

But he initiated the change, and within 18 months managed to bring forward that change. It was the beginning to other changes.

Lesson #2: Introduce automated testing

Some teams feel helpless when they have no tests. They’re stuck, they feel there’s no escape. But it is possible to start at zero and achieve an effective test suite:

“From 0 tests to effective automation test suite” - Nik Sumeiko

This is what I often had to do as a Technical Coach, I’d work with teams that had zero or very few automated tests. I helped them retroactively introduce testable architecture, automated tests and helped refactor those tests to be more effective at catching bugs and easier to maintain.

That’s why a big focus in my TDD in Legacy Code series is step-by-step guidance how to introduce automated testing in a legacy project, starting even with zero tests.

Lesson #3: Introduce TDD

Some teams might think that if they’re practicing Test Last, that it’s not possible to move to TDD. But actually, it’s possible:

“From testing last to Test Driven Development” - Nik Sumeiko

Based on my work as a Technical Coach, I found that a big barrier to TDD is actually that even Test Last isn’t done well! That’s why I’d firstly help the team practice Test Last proficiently, so that they’d feel comfortable writing tests. The other reason why we didn’t just jump to TDD is to enable the team to feel the pain of retroactively redesigning architecture & code to be testable, and to see the low mutation code coverage scores (despite high code coverage scores) - to see that the tests they’d write with Test Last wouldn’t protect them against regression bugs.

I reflected this in my TDD in Legacy Code series, where at every level, we firstly focus on how to do Test Last effectively and then introduce TDD at that level. That way, the team is much more ready, and they can see the difference it makes.

Share your success story

I’d like to feature TDD success stories in future editions. To share your story, write a comment below. 💪

---

Want to apply TDD in practice?

You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project. Access TDD in Legacy Code.

---