And I'm trying to explain that complexity is not cause by over-abstractions, but instead, solved by it.
Yes, certainly the integration tests are part of the codebase (allthough some people argue that tests are not part of it, I strongly disagree). But they are abstracted away.
Neatly in their own directories. Using their own class and dependency hierarchies, having the proper dependecy-directions (the UI tests depend on the UI-layer, but the UI-layer does not depend on the tests). And so on.
If you truly believe that the solution to hard-to-understand-complexity is to have less complexity, I'm afraid you'll be dissapointed: all projects will compe with ever growing essential complexity. Even if you avoid all accidental complexity, you'll have to deal with the essential complexity. And our main tool to do that is abstractions. From an OS abstracting the hardware away, to database-servers to libraries for that database-service and so on. The solution may be to say: I don't want a database (and can forego the db-lib connecting to the db-servers, which run on an OS) but if the database is essential complexity: abstract it away.
That's fair - I'm not against abstraction in general. I agree that we wouldn't be able to handle the essential complexity of software without it.
I'm just saying that each abstraction also has a cost, and makes understanding the whole thing more difficult. Abstraction is, in my understanding, a necessary but costly tool.
A lot of my thoughts are summarized well by Brian Will in this video:
Yes, certainly the integration tests are part of the codebase (allthough some people argue that tests are not part of it, I strongly disagree). But they are abstracted away.
Neatly in their own directories. Using their own class and dependency hierarchies, having the proper dependecy-directions (the UI tests depend on the UI-layer, but the UI-layer does not depend on the tests). And so on.
If you truly believe that the solution to hard-to-understand-complexity is to have less complexity, I'm afraid you'll be dissapointed: all projects will compe with ever growing essential complexity. Even if you avoid all accidental complexity, you'll have to deal with the essential complexity. And our main tool to do that is abstractions. From an OS abstracting the hardware away, to database-servers to libraries for that database-service and so on. The solution may be to say: I don't want a database (and can forego the db-lib connecting to the db-servers, which run on an OS) but if the database is essential complexity: abstract it away.