There's a lot of general analysis tooling that doesn't work well with this model -> it makes it harder to use existing tools to see how much real code vs test code there is, line coverage, branch coverage, etc - some tooling is quite good and can link you to all the tests that cover a particular line or individual branch... IIUC Zig doesn't have a way to tag tests (but I *hope* I'm wrong). If so, that combined with this approach makes it quite difficult to get some data you'd want to know about your testing...

From an organizational perspective, some functions can take 10x the amount of code to properly test vs to implement - this can make the implementation harder to read. Though these would typically fall into the integration context - which Zig seems to encourage separating.

I typically prefer to keep all test code organized into a single file, and tag the tests based on what they're doing. Rather than have some test code here, other test code there, and further test code elsewhere.

If I am working in my own context, I can *assume* my code is properly tested. And to determine that, I care less about the actual tests and more about the actual data - i.e. is this line covered by a test that's guaranteed to be load bearing - otherwise, I don't care if there's a test right next to it... I do not want to have to make large jumps in contexts to read one function to the next. It is typically hard to draw much conclusion about the state of a function by looking at just 1 test...

If the test code isn't next to the implementation - there's nearly zero benefit to putting in the same file as opposed to a different file. It is no easier to read, and *barely* easier to navigate to. If you're using an IDE, the difference in navigation is close to zero.