In the api module, we currently have a bunch of integration tests checking that our custom resources can be created, deleted, scaled, etc. These tests are often slow (a big overhead of creating and deleting CRDs, not necessarily per-unit test time). And they also seem to be pretty inconsistent. The tests seem to cover for all of our CRD:
- Creation and deletion of a regular resource
- Creation and deletion of a minimal resource
- Scaling of scalable resources
- Assorted combinations of required fields, typed fields, missing required fields, invalid resources, etc. These tests never cover everything; they are just a random collection of things when someone decided to add something.
Lot of these tests do not seem to make much sense. If I forget to make something required in the API class, I will likely forget the test. And vice versa. So I think the added value is small for most of these tests.
I think it would make sense to give this a bit more meaning, consistency, and plan in order to really know what we want to test there and what should not be covered etc. So we should decide what do we want to here.
I'm happy to discuss this and listen to the opinions of others. But for the sake of the discussion and triage, I would start with the following proposal:
- For each resource we keep:
- Keep the minimal resource test
- Keep the regular resources test with a resource corresponding for example to one of our examples
- Add tests for the CEL validation rules which are currently mostly tested only manually
- We remove all the other tests for required fields, types, missing fields, invalid fields, scale subresource, etc.
- We make sure that the CRD Generator tests do checking of these features (required fields, types, missing fields, invalid fields, scale subresource, etc.) on its own artificial CRD which I think is currently used mostly just to verify the CRD YAML string to string. But it can be extended and used in actual integration tests.
In the
apimodule, we currently have a bunch of integration tests checking that our custom resources can be created, deleted, scaled, etc. These tests are often slow (a big overhead of creating and deleting CRDs, not necessarily per-unit test time). And they also seem to be pretty inconsistent. The tests seem to cover for all of our CRD:Lot of these tests do not seem to make much sense. If I forget to make something required in the API class, I will likely forget the test. And vice versa. So I think the added value is small for most of these tests.
I think it would make sense to give this a bit more meaning, consistency, and plan in order to really know what we want to test there and what should not be covered etc. So we should decide what do we want to here.
I'm happy to discuss this and listen to the opinions of others. But for the sake of the discussion and triage, I would start with the following proposal: