29 lines
1.6 KiB
Markdown
29 lines
1.6 KiB
Markdown
|
# Design decisions
|
||
|
|
|
||
|
|
`womm` mostly shadows the API of other test runners out there with a few quirks. This document records choices made
|
||
|
|
along the way and the reasoning behind them.
|
||
|
|
|
||
|
|
## No production dependencies
|
||
|
|
|
||
|
|
I believe that the NodeJS ecosystem is too trigger-happy with `npm install` and `yarn add`. Even basic applications
|
||
|
|
quickly end up requiring tens of packages to be shipped to users. A lot of those packages being maintained (or not) by
|
||
|
|
the community, this means that ensuring that the downstream dependency of a project can quickly become a major concern.
|
||
|
|
|
||
|
|
The best way to ensure that things are becoming stale is to depend on less, and depending on nothing than the standard
|
||
|
|
library is best.
|
||
|
|
|
||
|
|
_Some exceptions apply here. Development tooling is easier to handle, but should still be heavily vetted. For this
|
||
|
|
reason, `womm` has a few dev-facing dependencies, but those are carefully-chosen to make sure that the cost of having
|
||
|
|
them doesn't outweigh what they bring to the table._
|
||
|
|
|
||
|
|
## No snapshot matchers
|
||
|
|
|
||
|
|
Snapshot testing is rarely used well. In a lot of cases, it's a crutch used to avoid writing more precise assertions
|
||
|
|
about software behaviour. This is especially true in browser-facing code where component snapshots clutter codebases and
|
||
|
|
provide very little confidence that code is healthy -- instead, it measures whether it changed or evolved, and expects
|
||
|
|
whoever _reads_ the test to validate snapshot contents manually.
|
||
|
|
|
||
|
|
Snapshot matchers are not included out-of-the-box in `womm` to promote better practices around test quality and to
|
||
|
|
remove a foot-gun from the tooling.
|
||
|
|
|