> Because it signals to me that the only one who understands this piece of business logic that we have applied to our code base is a test, which is a piece of code.

That...makes no sense. Tests do not understand rules, nor do they (or are they intended to) fully encapsulate them. They are intended to capture specific instances of application of the rules that have been verified with the person(s) defining expectations—the customer for acceptance tests or unit tests of key business functions, but possibly the team itself when the test is a unit test of an implementation detail.

The test isn't the only one that understands the ruler, it's the output of a process that validates that the test writers (who are humans on the team) understand the rule, and also concrete examples which aid anyone who comes.later in understanding the rule.

To me, not having defined test scenarios (whether automated and thus part of the code base or not) is a signal that the team probably doesn't (and almost definitely doesn't if there has been turnover so that the implementors of the functionality are no longer on the team) fully understand the intended function of the code.

Do you trust any documentation at all? A test's just documentation a machine can read and, to some extent, validate. Other docs are necessarily even less trustworthy, if they can't be automatically checked for accuracy.

>>Do you trust any

The only test that matters to me is the one where a customer says "Yes, good!"

Sure, a test suite doesn't replace that. It helps ensure that test returns "Yes, good!", instead of "Why did you break this thing that worked last week!", assuming you know anything about what the customers consider good.

The parent sounds correct. One can have an extensive test suite and still turn out a product that is useless to the customer. These are 2 entirely separate concerns: testing is sanity checking that the code does what it is written to do, user validation is sanity checking that the code is actually useful to a customer (which most certainly cannot be automated or programmed).

> Because it signals to me that the only one who understands this piece of business logic that we have applied to our code base is a test, which is a piece of code.

That's a weird leap of logic. No, it does not mean that. It means that a human wo understood that piece of logic wrote a test, so the test can in the future warn about issues before a human spends time on checking if it still works like it should.

I disagree with the notion that this leap is weird.

>> No, it does not mean that. It means that a human wo understood that piece of logic wrote a test

I don't not trust a human to understand (1) a piece of logic nor to understand (2) a test written by someone who does not understand said piece of logic.

So how are you implementing code when you don't understand the logic of what it does? How do you make sure it does what it is supposed to do?