3 Comments

How do you make people aware of bad tests. It's a delicate topic.

Often people think they do the right thing because they read something

in a book. And then it's hard to convince them of the contrary.

Example 1:

Developers know TDD. They know that a good practice is to test public

methods *only*.

-> Consequence: Devs now start to make private/protected function

public in order to test them complying with the good practice. This

completely breaks information hiding and pollutes a clean interface

with random methods.

Another driving point here is testability or "testing drives good

design". If you make private function public you improve

testability but you screw up design...

Example 2:

Developers often are proud of a good code coverage, e.g. > 80%

-> Looking into the tests reveals that they include large

system/component/e2e test in the coverage statistics. Or they write

unit test with no assertions.

The learning here is no mantra is always true, IT ALWAYS DEPENDS!

Great advice from GeePaw Hill:

"It frustrates me greatly to see so many bright people come out with

harsh declarations of what you must always or never do, generally in

programming, and specifically in TDD. It's judgement, folks, and it's

judgement all the way down. Build your judgement, then use it."

https://twitter.com/GeePawHill/status/1416497997379166209

Expand full comment

Just 2 things.

1. Regarding private methods that never get exercised via the test cases that exercise the public methods: remind me why they exists? Coverage will at least reveal if there are dark corners like this, or even a decent IDE.

2. Regarding tests with no assertions: Mutation testing will sniff these out in a hurry.

Expand full comment

If the most effective incentives are social or intrinsic, for example my own ego, how can I put myself in check so that I can say 'no' to those incentives and instead look for others more meaningful?

Expand full comment