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
Some features, such as those proposed in #47 are intended to trigger complex behaviours in Kubernetes beyond the creation of some objects.
It can be argued that these features should be tested using unit tests that only verify that the xk6-kubernetes code being tested calls the Kubernetes API with the expected parameters (for example, create an object with the correct definition). However, this type of tests cannot guarantee that the resulting behavior in a live cluster is the expected. For instance, it cannot check that the developer has an incorrect understanding of the object's parameters to be used. Therefore, integration tests against a live Kubernetes cluster may be desirable.
One key question to resolve as a project is which tools to use for such tests in order to automate its execution. Multiple tools exits in the Kubernetes ecosystem such as :
Even when it is not strictly necessary to agree on a tool (as tests should only relay on standard Kubernetes APIs) it is convenient to document the process of setting up tests for at least one tool. Also, it is convenient that these tools are executed in the CI pipelines and therefore the compatibility with the CI/CD infrastructure is a key requirement.
The text was updated successfully, but these errors were encountered:
There is an implementation of this approach in the xk6-disruptor extension's cluster package which could be extracted as an independent package and be reused here in xk6-kubernetes for e2e tests.
Some features, such as those proposed in #47 are intended to trigger complex behaviours in Kubernetes beyond the creation of some objects.
It can be argued that these features should be tested using unit tests that only verify that the
xk6-kubernetes
code being tested calls the Kubernetes API with the expected parameters (for example, create an object with the correct definition). However, this type of tests cannot guarantee that the resulting behavior in a live cluster is the expected. For instance, it cannot check that the developer has an incorrect understanding of the object's parameters to be used. Therefore, integration tests against a live Kubernetes cluster may be desirable.One key question to resolve as a project is which tools to use for such tests in order to automate its execution. Multiple tools exits in the Kubernetes ecosystem such as :
Even when it is not strictly necessary to agree on a tool (as tests should only relay on standard Kubernetes APIs) it is convenient to document the process of setting up tests for at least one tool. Also, it is convenient that these tools are executed in the CI pipelines and therefore the compatibility with the CI/CD infrastructure is a key requirement.
The text was updated successfully, but these errors were encountered: