Interesting…TDD was never sold to me as helping break down problems, ease cognitive lead, etc. I’ve always seen it just as defining a way to test the requirements before implementation (which could steer the implementation), rather than the typical: implement (buggy) first, add edge cases later, add tests, still find bugs later.

Whether adding tests first or after implementation, I think the important part is that tests are essentially executable documentation for expected behaviour.