That depends on what we're testing, and how thoroughly. Tests as documentation are amazing when the specs are in flux and we'd rather document stuff in one place instead of duplicating it between tests and user manual. But when the specs are fixed this is much less of a problem.
Then there's how much you need to test. Good tests go way beyond readable examples, they usually involve generating tons of tests with more or less random data and running them in a loop (property based tests). I do this, and to be honest I wouldn't recommend end users read them.
Agreed, that's why I said it's a "big portion" and not "all" of what a test suite should be. Many tests are "how-to guides" in the Diátaxis documentation approach[1]. They're also useful as a part of tutorials. Anything over 25% is a pretty big portion of the total documentation.
Automated property-based tests, fuzz tester cases, and similar things aren't documentation at all.
Then there's how much you need to test. Good tests go way beyond readable examples, they usually involve generating tons of tests with more or less random data and running them in a loop (property based tests). I do this, and to be honest I wouldn't recommend end users read them.