I mean it sounds to me like testing is your only problem so it’s kind of hard to ignore.
Personally I prefer fewer larger modules over more smaller modules. Deeply nested code is harder for me to reason about, I need to push stuff on my stack more often as I go down a debugging rabbit hole.
You can never reason locally about a bug. All code looks good locally. Bugs always manifest in the totality of your code and that is where you have to look at it. Your unit tests for the release running on production are all green, someone reviews all those lines that are in there. Locally it all made sense, local reasoning is how you ended up with that bug in production.
If you write a small little class with one method to help implement some bigger interaction, if your change does not touch the unit tests of the ”wrapper” class actually implementing the bigger interaction, what the users use, you are likely writing meaningless code or your test coverage for the actual use cases is not good enough.
> if your change does not touch the unit tests of the ”wrapper” class
I don't think this is a good example. In fact, this is more supportive of having the small little class. The "wrapper" class only needs to have 1-2 unit tests to test the scenarios in which the small little class is invoked without needing to be concerned with the complexity of everything that small little class is actually doing. I've never written a small helper class without writing corresponding tests in the wrapper so I've never had that problem - it's usually the first thing I write after adding the helper class. For that specific problem there's automated and manual processes anyway. Code coverage tools can easily tell you if you missed writing tests for the invocation and reviewers should spot that in PR reviews.
I mean it sounds to me like testing is your only problem so it’s kind of hard to ignore.
Personally I prefer fewer larger modules over more smaller modules. Deeply nested code is harder for me to reason about, I need to push stuff on my stack more often as I go down a debugging rabbit hole.
You can never reason locally about a bug. All code looks good locally. Bugs always manifest in the totality of your code and that is where you have to look at it. Your unit tests for the release running on production are all green, someone reviews all those lines that are in there. Locally it all made sense, local reasoning is how you ended up with that bug in production.
If you write a small little class with one method to help implement some bigger interaction, if your change does not touch the unit tests of the ”wrapper” class actually implementing the bigger interaction, what the users use, you are likely writing meaningless code or your test coverage for the actual use cases is not good enough.