Tests separate from or close to code

[larsivi]

Back when I really learnt about unittests, it was when playing with D. One of the features of that language was the the ability to add unittests within any module such that the test was as close to the code as possible. This is something I generally like. You have gone the other route, putting all the tests in its own sub hierarchy.

What I am working with now, is a growing web/cloud application, node/react/typescript, where the code is a in a monorepo "managed" by pnpm. It is generally divided into modules/applications (things that runs) and packages (common functionality).

Basically unittesting operates on the packages, whereas the intention of the modules is to be minimal scaffolding and configuration. (Not so easy in practice, but not so relevant for the discussion points.)

Looking at the packages, there are basic stuff and more higher level stuff, and dependencies between them (no circular ones!). Unittests has sofar been added to each package. As I try to improve the tests (mock less, use more of the domain and fakes), more and more is common between packages (e.g. msw handlers, fake data providers, etc).

Some of these are actually their own packages, depended on as dev dependencies (considering putting some of them on github if they can be made generic enough).

All of this works, but I feel that I start to get too much management of the test stuff, and maybe that would be less of an issue if I put the tests into its own place?

Do anyone have thoughts on these questions?

[anderssv]

First of all, I think we agree: I want to keep the tests and code as 'local' to the code they test as possible. So a Fake should be 'close' to the real implementation. A test should be close to what it is testing, and test data should be close to the objects it constructs.

In Java/Kotlin that usually means in the same package. I must admit the packages here are a bit messy, and it is partly because it is a mix of a domain but also separate examples. So everything becomes a bit construed. And even out of sync between test and main.

But when it comes to the "own sub hierarchy" that is just convention in Java/Kotlin. The main benefit of that is that the build tools manage "scopes". So it is impossible to use code from src/test in src/main, but the other way around is posisble (use main in tests). This of course can create some challenges when refactoring etc. but the IDEs in general help to manage this as they automatically know this.

That being said: I should probably be a bit stricter with packages myself too (and analyze dependencies), but at least for navigation I find that I usually don't navigate folders much. Code Completion (especially in a compiled language), Click to go, Call Hierarchy and Implementations really makes me find things really fast without relying on the "physical" location.

Did that answer at least some of your questions?

[larsivi]

Absolutely! I think my gut feeling probably is right here - I should just make sure to refactor the tests and util packages/modules too, as things grow.

I'm a fairly heavy user of the IDE (WebStorm for this) and use search, click-to-go and other features a lot. I like the folder structure though, and sometimes I need to scroll it to figure out what I am looking for. I find that the structure also helps in various build/test setups where I need to differentiate various aspects and where there is proper separation of concern.