DEV Community

Discussion on: 4 reasons I fell in love with Test Driven Development.

Collapse
 
190245 profile image
Dave

Nowhere in my post did I say that products ship untested.

The debate is about either writing tests before code, or code before the tests (TDD or not).

Thread Thread
 
patferraggi profile image
Patricio Ferraggi

Hey Dave, sorry maybe I misunderstood, then what did you mean by this
"Tests are the first thing that PMO sacrifices for the timeline, because they're only seen by developers, and we pay QA for testing anyway, right?"

Here I understood that in some cases PMO decides not to test in order to meet the deadlines, is my understanding of your answer incorrect?

Thread Thread
 
dan1ve profile image
Daniel Veihelmann • Edited

Dave, fair enough, maybe I misunderstood your post.

However, from my (and my team's) experience, writing the production code before the tests will often lead to code that is simply hard to test.

I don't follow TDD strictly, but I certainly see it's value, especially for bug fixes.

Thread Thread
 
190245 profile image
Dave

No argument about TDD for bug fixes - you get clear, unchanging requirements in a bug fix. I personally follow TDD when fixing bugs.

Re the untestable code - I think that's something that just takes time. We have a few guys who write then have to refactor to write unit tests.

But (in our case) you can hit the minimum coverage targets by writing integration tests, and somewhat disregard good OO design principles and code patterns, and it'll still pass a build (though we tend to complain loudly in code review about future maintenance, and usually a PM interjects with "raise a tech debt ticket, we'll fix that in future, I promise" 🤔)

Thread Thread
 
190245 profile image
Dave

PMO doesn't decide anything (our PMs can barely decide what they have for breakfast).

However, it's a fact of life that because the requirements change mid sprint, the estimates are invalid without the expectation of delivery changing. This usually ends up in a negotiation, where the PM will flex the deadline a little and the Dev team have to flex a little from the ideal perfect world.

Specifically in my office, the CI server will throw an "amber warning" if code coverage is below 80% and we all try to keep it green. But if we have a tight deadline, we can sacrifice 20% test coverage and still release (the CI server won't let anyone release anything below 60%).

So, given the requirements change (other than bug fix), and deadlines are always tight, test coverage is an easy sacrifice - though that doesn't mean we don't write tests.