Well, certanly that is the problem.

Although you say that integration level would require more ellaborate test scenarios, and they would became harder to understand, I am quite sure that there is a compromise here.

One part essential when writing tests is also building a kind of DSL, so they are easier to understand. I do not mean to use Gherkin or something like that, you can just write a bunch of helper classes. But if you have the opportunity to deeple learn about BDD and Gherkin, its filosophy has a lot of hidden gems.

Another source that you can use is this video:

- https://youtu.be/2vEoL3Irgiw

It focuses a lot in Java, I do not know which language do you use, but some concepts are generic enough.

Another reason why you might have problems to do a higher level of testing, beyond QA unit test, it is probably because your code is coupled in too many ways. Divinding the different parts of the application in independent modules, and avoiding their load when testing through a kind of Plugin Architecture, would help a lot to reduce the setup boilerplate.

For example, currently my tests are about three and seven lines, and some times they are even easier to read, and understand, than their names. But that is because they only start what is necessary, and I have a pretty testing libraries that help me to focus. I had this old post in about when I developed my current strategy.

And of course, tests are the best documentation :-)