pinto_graveyard

> Also, neither feminists nor transgender folk scare me so discussing them in an academic setting

They scare me in a professional setting.

Many an unsuspecting individual was brought down by mere accusations of misbehavior towards those groups, context and evidence be damned.

> If you mock everything, you are not really "testing" anything but your internal logic.

That's the purpose of unit tests. They do not exclude the need to perform other kinds of test. Integration tests, contract tests, stress tests - all those will focus on different facets of a system.

> Most unit tests are written to ease the development. After finishing the development, they are safe to delete.

This is especially bad advice, unless no one will never touch that codebase ever again.

I saw old unit tests highlight bugs that would have been introduced by new code many times over the years.

> TDD and exhaustive unit testing make the maintenance process harder because you don't know if a test is useful or not.

Then, as a developer, remove unit tests that became useless.

Code coverage is a measurement. If you turn it into a goal, it will become useless. If you have "useless" unit tests, it tells me that some unit tests were written as padding to move code coverage up.

At least in the majority of places I worked at, people cared about readability and maintainability rather than just some abstract notion of "clean code".

And perhaps I was lucky, but typically readability and maintainability are orthogonal to performance and efficiency. Sometimes readable will have optimal performance, sometimes not. Then it becomes a matter of tradeoffs.