Is TDD Dead? (2014)

Re:Is TDD Dead? (2014) by GordonS on Wednesday August 26, 2020 @01:20PM (#24284682)

This is a rampant problem in the enterprise world, and it drives me nuts. I regularly have to work for clients who mandate using Sonar Qube (or/and other SAST tools) with strict policies, and also require 85%-100% test coverage on all projects regardless of how much sense it makes.

Predictably, teams have to spend way too much energy getting "waivers" approved by some ridiculous group, and inevitably end up creating tests that don't actually test anything, just to get the coverage figures up.

[ Parent | on HN ]

Re:Is TDD Dead? (2014) by lowbloodsugar on Wednesday August 26, 2020 @01:30PM (#24284831)

Can you give us an example of where it doesn't make sense?

[ Parent | on HN ]

Re:Is TDD Dead? (2014) by closeparen on Wednesday August 26, 2020 @01:51PM (#24285117)

In Go, it turns testing into a game of “how do I make this stdlib function return an error”?

[ Parent | on HN ]

Re:Is TDD Dead? (2014) by noisem4ker on Wednesday August 26, 2020 @02:57PM (#24285928)

Error handling taking up 50% of the code is definitely a problem with Go itself. For each meaningful line, there's an accompanying "if err != nil {return err}", so if you want coverage you end up testing this kind of boilerplate.

[ Parent | on HN ]

Re:Is TDD Dead? (2014) by GordonS on Wednesday August 26, 2020 @01:38PM (#24284945)

A trivial example would be getters and setters for plain old classes.

[ Parent | on HN ]

Re:Is TDD Dead? (2014) by lowbloodsugar on Wednesday August 26, 2020 @06:42PM (#24288150)

Surely the getters and setters of POJOs would be exercised in the tests of other classes? If not, why are they there?

[ Parent | on HN ]

Re:Is TDD Dead? (2014) by dropofwill on Wednesday August 26, 2020 @07:13PM (#24288366)

E.g. it’s public api in a library and they’re only used by other applications.

[ Parent | on HN ]