e2e: add test helper struct for contrast subcommands #268
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
malt3
approved these changes
Mar 25, 2024
burgerdev
force-pushed
the
burgerdev/e2e-lib
branch
from
a9dda95 to
8bae2ca
Compare
burgerdev
force-pushed
the
burgerdev/e2e-lib
branch
from
8bae2ca to
31baac3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This chain of commits adds a test helper struct that holds state for an e2e test and deals with executing
contrastsubcommands. It currently starts from the content created byjust populate, but should be fed withkuberesourcesonce we can patch images from Go.The idea of
ContrastTestis to be invoked from e2e tests with as little ceremony as possible, which is why it takes*testing.Targs everywhere. It should also provide high-level APIs to the outcomes of thecontrastcommands it runs (an initial example of these areMeshCACert()andRootCACert(), an obvious next step is access to manifests).The methods currently don't allow to customize the calls, but will eventually need to (we will want to call
Set()more than once to verify owner authentication, for example). We can think about introducing new functions for that,SetWithArgs()or something, but the current implementation is sufficient for testing the simple workflow and our example deployments, so I'd only add that when needed.