Modern TDD
Regression bugs in production! Slow delivery cycles! Business is complaining, yet IT still can't deliver software that works, on time. Too many bugs, late every time...
The IT industry still hasn’t solved the two fundamental problems:
There are many regression bugs! How to deliver software that works?
Software delivery is very slow! How to deliver software efficiently?
📢 My next Live Q&A Session about Unit Tests is on Wed 30th April 17:00. Here are some questions from our Q&A backlog:
How does TDD with sociable vs solitary unit tests affect TDD cycle length when implementing port behavior?
How to deal with unit tests & multithreading?
How to unit test abstract classes in libraries?
When we are testing Application Services (or Use Case Handlers) should we stub out Domain Services?
Which test doubles should we use in unit testing?
If you’re already a Paid Member of Optivem Journal, get your 100% discount ticket for Live Q&A.
Upgrade to join Live Q&A for free:
1. Manual Testing ➜ More Regression Bugs!
Regression Bugs are released due to Manual Testing. Manual Testing is very time-consuming both for QA Engineers & Developers.
Since developers don’t have time for full Regression Testing, it causes them to release many Regression Bugs to UAT.
QA Engineers don’t have time for full regression testing either, causing Regression Bugs to escape to Production.
2. Manual Testing ➜ Slow Delivery!
Slow Delivery is caused by Manual Testing which is time-consuming:
During the Development Stage, developers have to waste time manually debugging their own code.
When releasing to the UAT Stage, developers have to waste time debugging integration issues with other teams.
During UAT, QA Engineers have to waste time on manual regression testing, and developers have to waste time in expensive rework due to late bug discovery.
3. Test Last ➜ Slow Delivery!
Most companies perform testing at the end: firstly Requirements (PO), then Coding (Developers), and finally Testing (QA) last.
The problem is that many Requirements aren’t clear, so PO vs Developers vs QA each have different interpretations of the Requirements. It’s only when QA Engineers start writing Test Cases, that questions about scenarios emerge, and they discover that the Requirements aren’t clear.
Many times, QA Engineers report Bugs to developers which are the following:
Missing scenarios added by QA Engineers but not known to developers.
Different understanding of expected results of a scenario, whereby developers understood it one way, but QA Engineers understood it another way.
What’s the solution?
The root causes of Regression Bugs & Slow Delivery are: Manual Testing & Test Last approach. The solution is: Automated Testing & Test Driven approach.
Let’s see how TDD helps us:
TDD - System Level eliminates the need for Manual QA Regression Testing and helps eliminate misunderstandings between PO/QA/Developers regarding expected functionality from the user-facing perspective
TDD - Component Level minimizes the need for inter-team manual debugging & minimizes integration issues between teams
TDD - Unit Level eliminates debugging & enables cheap refactoring