openculinary / frontend

The RecipeRadar Frontend is a recipe search and meal planning application
GNU Affero General Public License v3.0
13 stars 2 forks source link

Experimental: use 'inline' unit testing approach #225

Closed jayaddison closed 8 months ago

jayaddison commented 1 year ago

Describe the reason for these changes and the problem that they solve

It's not great that code-under-test currently has to be exported from the source module (file) it exists in: we're often choosing between writing test coverage (:heavy_plus_sign: good -- we want more of that) or polluting module exports (:negative_squared_cross_mark: bad: we want the minimal set of inter-module exports/imports for the application).

Inspired by the way that Rust recommends organizing unit tests within the same code file as they're testing, a way to resolve this problem is to place the unit test code into the same file as the code it tests.

However: we want any unit-test-related imports to be omitted from the application bundle.

Fortunately there's a way to do that with webpack v5: configuring empty package aliases. Those modules will be ignored and not included in webpack's build output.

:warning: Currently some .ts files within the codebase don't compile when run via mocha with ts-node. That's likely due to non-standard TypeScript -- finding and resolving those errors will be worthwhile.

Briefly summarize the changes

  1. Consolidate the unit tests from .spec.ts files into their associated .ts files
  2. Add empty webpack aliases for unit-testing-related packages

How have the changes been tested?

  1. Unit tests continue to run and pass

List any issues that this change relates to Vaguely relates to #161.

jayaddison commented 8 months ago

This doesn't seem to be easily achievable at the moment; after attempting to revisit this with yarn v4, I'm not having much luck; tests pass (make tests) but the resulting application does not function in the browser (a JavaScript error about a.describe not being defined occurs).

There's no urgent need for this, as far as I'm aware, and the industry standard seems to be to separate JavaScript (or TypeScript) modules from their unit test modules, so let's stay with that approach for now.