Personal opinion here: I don’t think that code inspection and automated tests are mutually exclusive. We write automated tests primarily to reduce the cost of change, not so much to assert correctness.

One cannot really assert correctness with unit tests: as the creator of some code, if you knew that something was incorrect, you would just fix it, and if you don’t know that there is a bug lurking, you cannot write a test for it. We write tests to make sure that our code still does what it is meant to do in face of change. In other words, we write tests for our colleagues (or our future self) that will change our code in the future, so that they can do so knowing if/what they break. A well-tested project is easier to evolve.

Correctness can be inferred by manual tests and code inspections, better if by someone else than the code author. Code reviews and manual tests are about assuring quality.

I think the article is conflating these two aspect, and therefore sees a dichotomy where there is none.

I personally consider writing tests a worth investment of time, and one of the most valuable skills in coding. I also think that code reviews and a good quality assurance process are necessary.

Dude, if you want to talk to yourself, please just start a blog and get this over with?

It’s the same with you every time:

1. You express a strong opinion.
2. You claim it’s supported by science.
3. You cite a very sketchy paper (which, as I pointed out, doesn’t even qualify for a “paper” in the pure scientific terms).
4. You are passive-aggressive when criticised:

Q.E.D.

5. You start dancing on the edge of the forum rules by subtly telling people their opinion is bad:

There exists no evidence at all when we’re talking about ways to approach creating and maintaining a software project. There’s no OneAndOnly® solution; it all depends on the project. I don’t know why this is so hard to accept but I am giving up.

Seriously, at this point it speaks bad for me that I am even responding to you. I am taking it as a future improvement remark towards bettering myself.

Again, a friendly advice: if you like talking to yourself and don’t want your opinion discussed, just start a blog and disable comments.

“Evidence-based” is not a stick to beat other people with. Scientific literature is always subject to review: you cannot assume that because something is written in a paper, it’s proved and decided. Papers are part of the discussion, not the end of it. If you are implying that finding problems with a paper means being unscientific, I think you are misguided.

You cited a paper titled “On the Relation Between Unit Testing and Code Quality”. The paper could not find a strong link between unit tests and code quality. I think there are multiple problems with the paper, from the fact that code quality is not an unequivocal physical measurement like temperature, to the small sample size, making generalization at least dubious. Even then, the result is not surprising: I argue that testing is not about code quality, but about keeping cost of change down.

I would not be surprised to find that eating fruit and vegetables does not reduce the risk of getting struck by lightnings, but that does not mean that we should all stop eating them.

Also, beware of your own selection bias when cherry-picking studies.