There really is no benefit of splitting a functionality from it's test. Then you just have a commit in the history which is not covered by tests.
Splitting "handling the happy vs error path" sounds even worse. Now I first have to review something that's obviously wrong (lack of error handling). That would commit code that is just wrong.
What is next, separating the idea from making it typecheck?
One should split commits into the minimum size that makes sense, not smaller.
"Makes sense" should be "passes tests, is useful for git bisect" etc, not "has less lines than arbitrary number I personally like to review" - use a proper review tool to help with long reviews.
