You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Continuing with #61, let's add tests that verify that deploying a function works when multiple namespaces are enabled. A couple things we would really like to have
we still want to test when the namespace value is omitted, this is the implied "deploy to default namespace"
we probably don't need to test all of the non-default namespaces, so we are probably ok with just testing in the first value of config.Namespaces
ideally, these additional tests should be controlled by the config.Namespaces so that simply providing the CERTIFIER_NAMESPACES is enough to enable the additional tests. Similarly, if CERTIFIER_NAMESPACES is empty or does not exist, then it only tests the implied default namespace, see (1) above. Ideally, this means we do not need any additional configuration to control this.
the test Test_Deploy_PassingCustomEnvVars_AndQueryString actually looks like it should be in the invoke_test.go let's move and rename that appropriately. It isn't actually testing the deployment or configuration of a Function, rather it is testing the support for GET parameters during invoke.
Similarly, this since we have a separate file/flow for testing invoking, we don't need to have any function invocation in the deploy tests. For example, i think we can omit this line
Finally, one last improvement we could make to the tests is to consolidate the Test_Deploy_Stronghash, Test_Deploy_WithLabels, and Test_Deploy_WithLabels into a single table driven test. We can improve the tests in general by just always checking the name, labels, annotations, etc. For example, it is valid to verify that if the test case has an empty label set, then the deploy response should still be empty.
Putting all of that together, i think we end up with a single table-driven test TestDeploy where we have a sub-test for (at the minimum)
the minimal deployment, default and non-default namespace
deployment with non-empty labels, default and non-default namespace
deployment with non-empty annotations, default and non-default namespace
We can probably create this by creating the initial list of test cases
cases:= []struct{
namestringreq sdk.DeployFunctionSpec
}{
// cases here
}
and then we can just loop over it to add a copy of each test with the non-default namespace
defaultCases:=len(cases)
fori:=0; i<defaultCases; i++ {
newCase:=cases[i]
// rename the case// set the req Namespacecases=append(cases, newCase)
}
The text was updated successfully, but these errors were encountered:
Continuing with #61, let's add tests that verify that deploying a function works when multiple namespaces are enabled. A couple things we would really like to have
config.Namespaces
config.Namespaces
so that simply providing theCERTIFIER_NAMESPACES
is enough to enable the additional tests. Similarly, ifCERTIFIER_NAMESPACES
is empty or does not exist, then it only tests the implied default namespace, see (1) above. Ideally, this means we do not need any additional configuration to control this.Test_Deploy_PassingCustomEnvVars_AndQueryString
actually looks like it should be in theinvoke_test.go
let's move and rename that appropriately. It isn't actually testing the deployment or configuration of a Function, rather it is testing the support for GET parameters during invoke.deploy
tests. For example, i think we can omit this linecertifier/tests/deploy_test.go
Line 91 in bad219a
Test_Deploy_Stronghash
,Test_Deploy_WithLabels
, andTest_Deploy_WithLabels
into a single table driven test. We can improve the tests in general by just always checking the name, labels, annotations, etc. For example, it is valid to verify that if the test case has an empty label set, then the deploy response should still be empty.Putting all of that together, i think we end up with a single table-driven test
TestDeploy
where we have a sub-test for (at the minimum)We can probably create this by creating the initial list of test cases
and then we can just loop over it to add a copy of each test with the non-default namespace
The text was updated successfully, but these errors were encountered: