Our test suites should usually be constrained to individual files, to delineate areas of concern for our programmer-colleagues. Organizing these test files to form a coherent part of a larger code base can be a challenge, though.

Imagine a small JavaScript code base with the following directory structure:

app/
  components/
    ClockComponent.js
    GalleryComponent.js
  utilities/
    timer.js
    urlParser.js

It's quite typical to place tests relating to particular code in sub-directories close to where that code resides. In our example code base, we may create the following tests sub-directories to contain unit tests for our components and utilities:

app/
  components/
    ClockComponent.js
    GalleryComponent.js
    tests/
      ClockComponent.test.js
      GalleryComponent.test.js
  utilities/
    timer.js
    urlParser.js
    tests/
      timer.test.js
      urlParser.test.js

Here are some additional notes regarding conventions, which, as we should know by now, are vital in increasing the familiarity and intuitiveness of a code base and hence its overall cleanliness:

• Tests are sometimes called specs (specifications). A spec is typically no different to a test, although, as a name, it is slightly more favored in the BDD paradigm. Use whichever you're comfortable with.
• It's common to see test files suffixed with .test.js or .spec.js. This is so your test-runner can easily identify which files to execute, and it is a helpful reminder to our colleagues as well.
• It's not rare to see test directories with naming patterns involving underscores or other atypical characters, for example, __tests__. These naming patterns are usually used to ensure that such tests are not compiled or bundled as part of your main source code and are easily discernible by our colleagues.
• E2E or integration tests are more commonly placed at a higher level, which alludes to their dependency on multiple parts. It's quite common to see a high-level e2e directory (or some adaptation). Sometimes, integration tests are named individually and stored at a high level; other times, they are interspersed with unit tests throughout a code base.

Once again, hierarchy is key here. We must ensure that the hierarchy of our directories helpfully mirrors the conceptual hierarchy of our code and its problem domain. As an equal and important part of a code base, a test should be placed carefully and appropriately within a code base, not as an afterthought.