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.

I do not see that in the article. Qualities of inspections and testing were compared.
Another study with comparable results:

The study is from 2001, maybe right before the agile manifesto and the writings + thorough empirical studies of PhD Uncle Bob and other agile professors at diverse universities?

• You may actually be able to bypass unit test if the Inspection results are good

This implies that the study considers inspections and unit tests some interchangeable alternatives. I think they are not alternatives, they serve different purposes.

We want to use test to verify and validate functional correctness, not for defect removal and associated rework costs.

This also indicates that the article evaluates testing a way to assert correctness. I think automated tests are primarily a way to keep the cost of change low.

I think this is unnecessarily sardonic. We can discuss merits and demerits of agile or testing without mocking people.

The purposes have an overlap in that both serve the purpose of checking correctness.

I don’t get this. Automated tests are full of assertions. If you mean the safetynet that you construct:

you do inspections after changes also. Unit tests have a cost when changing code. You have to maintain them. Functionality changes, functions are removed and created, names of functions change, their signature changes.

I like to work fact-based, empirical research like

shows reviews to be more effective than testing. See 3.5 Review versus testing and 4.1 Cost and benefits

Claims by Uncle Bob and other agilistas about unit testing are not scientifically proved, for me they belong to the realm of pseudoscience. Moral imperatives (f.e. from Uncle Bob “if you don’t do TDD, you are unprofessional”) are unnecessary, and harmfull. I cannot take them serious.

An example of a highly ranked scientist and programmer that is not enthousiast about safetynets:

For more see the interview https://www.informit.com/articles/article.aspx?p=1193856

Read this thread BDD / TDD criticized by the way?

Well that’s exactly the problem – they shouldn’t be compared because they are two different tools serving different purposes.

It’s like being forced to choose between a wrench and a hammer, you know?

Nothing that relates to management of people is scientifically proven, as far as I know. Management involves psychology and working with different kinds of character traits in people – and that simply cannot be generalised and put in a comprehensive theory by science in its current form. Nor there are any large-scale experiments that prove anything beyond any doubt.

Bringing science to discussions about management is fruitless. When we discuss it, we are basically all alchemists arguing which exact ingredients will yield gold bars when mixed in the right pot.

I think it’s important we all recognise that. These “papers” you quote have a number of omissions when contrasted with the pure scientific method (like having large sample sizes, asking people from many different areas, analysing responses based on multiple factors, actively working to remove bias etc.). At best, they are from people who claim to have an epiphany after a long career. And they have a bunch of pals in a few universities that pat them on the back and sign their work without much scrutiny. Boom, the paper is now “credible”. That’s all there is to it and let’s please stop pretending otherwise.

So in this regard, your approach of citing very sketchy sources is ill-placed and won’t help with any discussion you might be willing to ignite.

As I said: “The purposes have an overlap in that both serve the purpose of checking correctness.”

This is about unit testing, not about management.

I respectfully disagree.

As I wrote, I think the main purpose of automated tests is not, in fact, checking correctness, but rather minimizing the cost of changes. A poorly-tested project is hard to evolve, as everything you change can break something else.

Code inspections and quality assurance are for checking correctness. A project where no code inspections or quality assurance is performed is more prone to contain defects.

I therefore think that comparing code inspections with tests is comparing apples with oranges: both are necessary, for different purposes, and they are not interchangeable.

A large extent of the paper you quoted is based on anecdotal evidence and subjective interpretation by the author. To me it sounds a bit as if someone was saying: “Seatbelts and headlights were compared as a mean to reduce car accidents in low visibility. Keeping headlights on proved more effective, so they can replace the need for seat belts. Also, seat belts give users a sense of false security.”.

The testing practices described in the article are quite far from agile: in many passages, it sounds like the subject of the article performs testing as an afterthought, possibly executed by different people, as opposed to as part of the development process. For example, it advocates for testing after the code inspection is performed. I intend testing as an integral part of development, and performed by the developer themselves (no matter if one practices TDD or not, TDD is not the point here).

I do think that agile practitioners sometimes go overboard, that sometimes agile is deployed as a mean of controlling rather than as a good software practice, and that in some contexts it takes on the traits of a cult rather than a practice. I also believe that the principles of iterative development and testing as part of the development process are still valuable.

If it was just about asserting correctness and detecting bugs, a round of manual testing would do just as well. You might happen to catch some bugs by running your automated tests, but you won’t catch what you didn’t design the tests for. Simplifying, you cannot reveal a bug that you don’t know of, and if you knew about it you could just fix it.

The value of automated tests is that, once written, they become part of your test suite, pinning down the invariants that should remain even when the implementation details are changed. Every time someone changes some code, the test suite informs them if some of those invariant was inadvertently broken.

The biggest cost of writing tests is payed only once, but you can run the same test as many time as you want during the development process. Therefore, they are efficient to safeguard against breaking functionality while evolving your project.

Inspections and manual testing have a cost every time they are performed. They are a better way to assert correctness and quality of newly added features, but re-inspecting or manually testing everything upon every change would be inefficient.