Fork me on GitHub

This may be a dumb question, but how are people deciding to split and name their different testing levels? e.g., have a test/unit and test/integration; but if I say unit test, I’m going to have test/unit/foo/bar_test.clj, with test-ns If I also want to have integration tests, I’m going to have test/integration/foo/bar_test.clj, with test-ns I now have two identical namespaces. I want to keep the parity between the src and test namespaces, so stuff like “jump to test file” works. So how is everyone else doing it?


Although I guess after reading it, “jump to test file” wouldn’t work anymore regardless, so that’s a non-issue.


Are people essentially just prefixing the unit. and integration. onto their namespaces?


For a concrete example; unit testing vs real-http-request testing a ring handler and cleanly separating the two


We're actually grappling with something similar at work, but at a more fundamental level "what is a unit test?", "when is a test considered integration?" etc. At a glance, it seems like pre/postfixing, that's what I'm currently doing with generative tests.


@U0E2EQFME my integration tests generally are organized by the features they test, rather than the namespaces under test. Since they integrate multiple pieces there is no one-to-one mapping between test and namespace there.


I 100% agree with @U07FP7QJ0 — In my experience you’re much, much better organising applications by vertical features at the top rather than by horizontal concerns. Within a feature you can then split horizontally if you need to. i.e. app.tweet app.profile rather than app.handler app.middleware app.models … Tests then follow a similar structure - though you may have something like