How Obeying to TDD Saved me Time
Obeying to the TDD (Test Driven Development) saved me a lot of time so I decided to write about it. It nicely shows the real-life advantage you can get from following TDD.
Now, to keep it short - few days ago I was writing some business logic that did some audit recording changes. For the sake of brevity imagine it was something between those lines:
public void recordAudits(Data data) {
if (data.someCondition()) {
recordAudit(auditA)
} else {
recordAudit(auditB)
}
Now, the current unit tests were in-place and were using some utility class for finding if the expected audits were recorded:
@Test
public void shouldRecordAudits() {
// given
Data data = ...;
// when
data.recordAudit();
// then
assertThatAuditIsStored(auditA);
}
The tests were running nicely and the green bar was visible, so we all thought we’re all good.
My work was to add some new audits to the business logic. I’ve decided that before I do that I’ll write a test that checks what I want to achieve. You know - it’s one of those red bar tests - I’m expecting it to fail, but I want to have it, so when I write the actual code I’ll just rerun it and it will pass.
I’ve written this test and - surprise - it passes! I hardly believed that I managed to write the business logic with
my mind power, so I start digging. I found out that in some point in the past someone modified this nice helper
method assertThatAuditIsStored(-) in such a way that in some cases it wasn’t actually testing if the given audit
was stored. Tests were still green (no fails), code reviewers omitted it (it was nicely hidden) and it ended up in the codebase.
Bottom line is:
If I wouldn’t write the test in the first place and expect the red bar but just instead write some business logic and then write the test I would end the day being sure that the logic is behaving fine and it’s test-covered. That’s why the first part of the TDD - to write not-passing test - is so important and cannot be omitted.