4 ms·
A couple of extra points I've found useful: The first test of a class of tests is the hardest, but it's almost always worth adding. Second and subsequent test
by andrewaylett 2y ago
A couple of extra points I've found useful:
The first test of a class of tests is the hardest, but it's almost always worth adding. Second and subsequent tests are much easier, especially when using:
Parametrised tests let you test more things without copying boilerplate, but don't throw more variants just to get the count up. Having said that:
Exhaustive validation of constraints, when it's plausible. We have ~100k tests of our translations for one project, validating that every string/locale pair can be resolved. Three lines of code, two seconds of wall-clock time, and we know that everything works. If there are too many variants to run them all, then:
Prop tests, if you can get into them. Again, validate consistency and invariants.
And make sure that you're actually testing what you think you're testing by using mutation testing. It's great for having some confidence that tests actually catch failures.
- otoolep 2y ago>The first test of a class of tests is the hardest, but it's almost always worth adding. Agreed, this has been my experience too.
- oweiler 2y agoThat's why I prefer test frameworks that make parametrised tests so easy that they become the default. Kotest and Spock are such frameworks.
- andrewaylett 2y agoGreat :). We use Junit5, and a mixture of @EnumSource, @MethodSource, and dynamic tests. Or Pytest, or a short shell script, or Busted, or Jest, or Node's built in test runner, or a "--selftest" flag to a variant of the native executable.