TDD in Legacy Code - ATDD for User Stories
Miscommunication about requirements is a huge problem in software development - causing conflict between the PO, Developers & QA Engineer. How do we reach alignment? Use ATDD.
🏝️I’ll be on vacation from January 1st to January 9th. During my vacation, you’ll still receive my scheduled articles, but I won’t be responding to Substack comments or chats. Feel free to continue working on your Sandbox Project and commenting on the articles. I’ll review your work when I return on January 10th.
🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series. To get these articles in your inbox every week, subscribe:
Writing Acceptance Tests at the end? Chaos.
When working in Legacy Code, the team was used to a siloed way of working, where developers do coding, and then QA does testing. So they see testing as something that comes at the end.
This means, even after learning automated Acceptance Testing, we might be drawn to old habits - writing those Acceptance Tests at the end.
But what happens when we write Acceptance Tests at the end?
We may discover that we actually don’t understand the Acceptance Criteria, that the Acceptance Criteria wasn’t written in a testable way
We may discover that the PO had one interpretation of an Acceptance Criteria, Developers had another interpretation, and QA Engineer had yet another interpretation
Writing Acceptance Tests at the start? Alignment.
So how do we solve the problem of misinterpretations and misunderstandings?
Start by eliminating silos. Even though the PO has ownership over Acceptance Criteria, the whole team should be involved in Backlog Refinement, so that the Acceptance Criteria is written in a testable way.
Since we have testable Acceptance Criteria, we can convert it to Acceptance Tests before starting implementation. For new User Stories, we should be applying ATDD.
How to practice ATDD on User Stories
After refinement, a User Story should have testable Acceptance Criteria. We can incrementally take each Acceptance Criteria, one by one: convert the Acceptance Criteria into an Acceptance Test, implement code changes to the System so that the Acceptance Test is passing (indeed, all the Acceptance Tests should pass), and finally refactor if needed (ensuring that all the Acceptance Tests are still passing).
Here are the steps to introduce ATDD for new User Stories in Legacy Code. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. I’ll review & provide feedback in the comments: ⬇️⬇️⬇️