k3d-dev needs tests
Recently a major feature of k3d-dev was broken by a well-intentioned refactor that introduced regressions. There is no detailed test plan or automated testing harness for k3d-dev. As a result, when the merge happened, despite the good faith efforts of authors and reviewers, the breaking code was introduced and impacted users.
We can do better. We need to have either:
- A detailed testing plan for k3d-dev that specifically outlines the supported use cases, how to execute them, and how to test if they were successful. This plan should be sufficiently detailed that anyone making change to the script can follow it and provide proof of testing, even if they are unfamiliar with the technologies in play (such as metallb, weave, or even bigbang). OR
- An automated testing harness that performs automated testing of known supported use cases and provides assertions that such use cases remain functional after incoming changes are applied. This proof should be provided on the merge request.
Test cases should be as small and simple as possible, and should be self contained. Avoiding reliance on external dependencies (such as the bigbang umbrella chart) will reduce the fragility of the test harness.
Regardless of which approach is chosen, before merging any changes to k3d-dev, we MUST acquire positive proof that the agreed upon testing procedure has been followed and all applicable use cases have been proven to pass testing.