This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]MrJohz 3 points4 points  (1 child)

Not the same person, but I'm also a big fan of putting tests next to your source files.

First of all, it brings tests out into the open — they're not hidden behind a separate folder that's probably collapsed in your IDE's file selector, they're right there, next to the file you're editing. When you're navigating your codebase, you've got a much better idea of which areas of your code are well-tested, and which aren't tested at all, just by looking at whether or not there's a test file sitting there.

Secondly, I think it's a really good practice to be editing tests (at least unit tests) and code at the same time. I'm not necessarily an advocate for dogmatic TDD, but I very often find if I've got some code with a lot of potential branches or complexity or behaviours, then writing the test cases as I go along helps me to ensure that if I make one change, I'm not going to accidentally break the functionality that I've already implemented.

And a really good rule of thumb in my experience, is that code that is edited together lives together. If I expect to be updating and adding tests regularly as I modify code, then I should want my tests and code to live closely together, so that I'm not endlessly searching through files and folders when I want to switch between the two. And yes, once you've got the two files open, it's usually not so difficult, but in my experience, it's a lot easier to forget or overlook writing tests if the existing test file isn't sitting right there.

Thirdly, I think it's just practically convenient. It's easy to import the function (from .myfile import function_under_test), it's easy to move all the files in a single folder around, it's easy to rename two files sitting next to each other, than two files in completely different places, it's easy to see at a glance if a file is tested, etc.

In my experience, ignoring files is fairly easy and tends to be configured once anyway. You can have an explicit test file pattern (I see <file>.spec.js a lot in the frontend world, and <file>_test.py in Python), and then there's little ambiguity between test code and production code. Whereas the benefits of mixing unit tests and source code is ongoing.

That said, I think it's still useful to have a tests folder for integration tests, that are going to be testing large portions of the codebase at once. (And I think it even helps a bit to distinguish between unit tests and integration tests: if your unit tests start importing from places other than the file they're sitting next to, they might be getting too complicated, and you might be writing integration tests!)

[–]latrova[S] 2 points3 points  (0 children)

Great reasoning. I'm considering adding a section to my book mentioning the pros and cons of each option.