[nfrbc]

I completely agree with the code coverage part.

A previous codebase I worked in was terrible to refactor because of the insane amount of tautological unit tests and abuse of mocking.

For new features we stopped writing tests that were too specific and started writing more integration tests. We achieved a leap in quality and ease of development.

[dwoot]

This! I'm working in a codebase at the moment where unit tests do the following:

1. cross multiple boundaries (integration test) by asserting that some system two degrees away from itself is being run/invoked (not a unit test's duty)

2. test descriptions read along the lines of, "it should work for valid use cases". This one made me laugh when I first saw it. This made refactoring a HUGE undertaking as I had to comb through all of it to understand it

3. mocking systems that weren't created by "us" -- this resulted in blind spots in various places

Test/code coverage is only one of many metrics to consider. I think it's useful, but its utility heavily relies on the quality of tests that are written.

I'm beginning to think that a hallmark of a good developer is one that understand what tests need to be written and what assertions must be made. This shines when the tests are written such that the developer can see how API design affects testing. I've worked in both functional and imperative languages and FP testing is harder to screw up as it forces the use of dependency injection. The idea of DI and inserting role players in imperative langs makes testing easier and shows that someone has thought about a reliance on behavior rather than concretions. So when I interview people, I always ask about dependency injection and polymorphism.

But working with seemingly more experienced (on paper) than me, I know that experience is also a terrible metric to rely on.

[nfrbc]

I had all three of the things you described. But let me add a new one to the list that was incredibly frustrating:

4. Instead of integration tests (or static typing), all systems made by a couple programmers only had unit tests. The call boundary was NEVER tested, and everything relied on RSpec's "allow(obj).to receive" mocking.

So, not only it was very difficult to refactor (because I had to change two or more different sets of tests + mocks), the tests for dependencies didn't fail when I changed function signatures, or even if I removed chunks of code randomly. I had to find which test to change by myself.

In the end we had tests and we had coverage, but they didn't test anything properly and made maintenance a major pain in the ass.