4 ms·

Can someone please explain to me the rational for shoving your tests in the same place as your code? I have seen this before, and every time i have tried it on

Can someone please explain to me the rational for shoving your tests in the same place as your code? I have seen this before, and every time i have tried it on anything beyond a simple project it has ended up becoming a nightmare. Often times you have numerous test specific helper functions, and tons of other test oriented cruft, where do all these things go? The root of the project? Also where do tests that encapsulate logic between multiple components go?

arethuza 9y ago
That's a problem I always have with these kinds of things - when someone says "Place your test files next to the implementation" I always find myself thinking what the reasoning is behind the rule. For that particular recommendation I can see arguments both ways - mind you I keep tests separate myself but I'd be interested in reasons for keeping them together.
- awjr 9y ago
  I suspect it's an audit trail. You see the set of tests there. One issue is that I think this conflicts with the recommended Component/index.js or Component.js not Component/Component.js I find you do want to find components through your editor (e.g. <cmd>+p in vs code) Finding lots of index.js doesn't help. You will in effect create a Component/Component.js but also use Component/index.js to export the Component.js Also if you use Jest this sort of falls apart.
- baseonmars 9y ago
  For me (and the teams I work with) it's to encourage modular thinking - everything is a candidate module that can be extracted, put in source control and shared. For tests that go beyond small (unit/spec) level we have a project level tests folder because these tests make use of multiple modules and it wouldn't make sense to place them closer to the code. Someone else in comments mentioned cohesion - that's another way of thinking about it.
lhnz 9y ago
> Can someone please explain to me the rational for shoving > your tests in the same place as your code? Basically, (1) you are quickly able to see whether a test exists for each file without needing to explore a different directory structure (and therefore it's easy to open the tests for a file), (2) the require/import paths are not like '../../../../../' (which is awkward to reason about) or requiring alias resolver configurations (which are environment-specific and fragile), and (3) you are not maintaining an extra directory structure which could diverge by accident. > Often times you have numerous test specific helper > functions, and tons of other test oriented cruft, > where do all these things go? > The root of the project? Also where do tests > that encapsulate logic between multiple components > go? Modularise and publish any test helpers which are actually general so they can be imported where they are needed. And if they are too specific for this to make sense, why are they being shared? Tests which encapsulate logic between multiple components should be next to the file in which you implemented this logic. If you're still unsure on how this is possible, investigate a large modern JavaScript project [0]. Many of these are successfully implemented in exactly this way. There are always edge-cases that go against what I've said, but in a big enough project you will also be able to see this. [0] https://github.com/facebook/react/blob/master/src/renderers/art/__tests__/ReactART-test.js https://github.com/facebook/react/blob/master/src/renderers/...
- camus2 9y ago
  These aren't "best practices" no more than how I organize code is "best practice". These are purely opinions and shouldn't be called "best practices".
  - lhnz 9y ago
    Points (2) and (3) are fact and not opinion. And it's clearly not an opinion that many large, modern JavaScript codebases are following this practice effectively. I linked to 'React' itself as proof of this... Also, I personally never used the term "best practice" however I will say this: (1) these practices are common within some of the most popular JavaScript projects, and (2) having used them and also previously stored tests separately, I do prefer storing tests alongside the files I am testing for the reasons I stated. I am not sure why, but your response felt a bit like you were angry with me, and putting words in my mouth.
wereHamster 9y ago
If you use type annotations you basically already do that. The type (assertions) are mixed right into the business code! And from there it's not much of a leap to keep the unit tests close by. Integration tests and other, larger tests should still be kept somewhere else, because they often not test a single component (or a single module) but a larger part of the whole application which is harder to pinpoint in the filesystem. So most people put those tests under a top-level tests/ folder inside the project.
- camus2 9y ago
  > If you use type annotations you basically already do that. The type (assertions) are mixed right into the business code! And from there it's not much of a leap to keep the unit tests close by. Unit tests are about testing behavior, not types. Using type annotations has nothing to do with testing. Putting tests right along the source code is a matter of convenience thus an opinion. In some languages like Go it is even "good practice".
  - lmm 9y ago
    Good types express behaviour.

arethuza 9y ago

That's a problem I always have with these kinds of things - when someone says "Place your test files next to the implementation" I always find myself thinking what the reasoning is behind the rule. For that particular recommendation I can see arguments both ways - mind you I keep tests separate myself but I'd be interested in reasons for keeping them together.

awjr 9y ago
I suspect it's an audit trail. You see the set of tests there. One issue is that I think this conflicts with the recommended Component/index.js or Component.js not Component/Component.js I find you do want to find components through your editor (e.g. <cmd>+p in vs code) Finding lots of index.js doesn't help. You will in effect create a Component/Component.js but also use Component/index.js to export the Component.js Also if you use Jest this sort of falls apart.
baseonmars 9y ago
For me (and the teams I work with) it's to encourage modular thinking - everything is a candidate module that can be extracted, put in source control and shared. For tests that go beyond small (unit/spec) level we have a project level tests folder because these tests make use of multiple modules and it wouldn't make sense to place them closer to the code. Someone else in comments mentioned cohesion - that's another way of thinking about it.

lhnz 9y ago

> Can someone please explain to me the rational for shoving > your tests in the same place as your code? Basically, (1) you are quickly able to see whether a test exists for each file without needing to explore a different directory structure (and therefore it's easy to open the tests for a file), (2) the require/import paths are not like '../../../../../' (which is awkward to reason about) or requiring alias resolver configurations (which are environment-specific and fragile), and (3) you are not maintaining an extra directory structure which could diverge by accident. > Often times you have numerous test specific helper > functions, and tons of other test oriented cruft, > where do all these things go? > The root of the project? Also where do tests > that encapsulate logic between multiple components > go? Modularise and publish any test helpers which are actually general so they can be imported where they are needed. And if they are too specific for this to make sense, why are they being shared? Tests which encapsulate logic between multiple components should be next to the file in which you implemented this logic. If you're still unsure on how this is possible, investigate a large modern JavaScript project [0]. Many of these are successfully implemented in exactly this way. There are always edge-cases that go against what I've said, but in a big enough project you will also be able to see this. [0] https://github.com/facebook/react/blob/master/src/renderers/art/__tests__/ReactART-test.js https://github.com/facebook/react/blob/master/src/renderers/...

camus2 9y ago
These aren't "best practices" no more than how I organize code is "best practice". These are purely opinions and shouldn't be called "best practices".
- lhnz 9y ago
  Points (2) and (3) are fact and not opinion. And it's clearly not an opinion that many large, modern JavaScript codebases are following this practice effectively. I linked to 'React' itself as proof of this... Also, I personally never used the term "best practice" however I will say this: (1) these practices are common within some of the most popular JavaScript projects, and (2) having used them and also previously stored tests separately, I do prefer storing tests alongside the files I am testing for the reasons I stated. I am not sure why, but your response felt a bit like you were angry with me, and putting words in my mouth.

wereHamster 9y ago

If you use type annotations you basically already do that. The type (assertions) are mixed right into the business code! And from there it's not much of a leap to keep the unit tests close by. Integration tests and other, larger tests should still be kept somewhere else, because they often not test a single component (or a single module) but a larger part of the whole application which is harder to pinpoint in the filesystem. So most people put those tests under a top-level tests/ folder inside the project.

camus2 9y ago
> If you use type annotations you basically already do that. The type (assertions) are mixed right into the business code! And from there it's not much of a leap to keep the unit tests close by. Unit tests are about testing behavior, not types. Using type annotations has nothing to do with testing. Putting tests right along the source code is a matter of convenience thus an opinion. In some languages like Go it is even "good practice".
- lmm 9y ago
  Good types express behaviour.