-
Notifications
You must be signed in to change notification settings - Fork 293
Implement multi-stage test registry interface #98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement multi-stage test registry interface #98
Conversation
891760a to
add088b
Compare
stevekuznetsov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good first start!
General comment -- we should make the new type of test just another option, like all of the others we have in the larger TestStepConfiguration -- this will mean we get a lot of validation for free. Once we do that, we should ensure we have new unit tests for those validations.
Also, we'd like to validate that no two steps in the resulting TestFlow have the same name, so we should add a validation function there and unit-test that as well.
The implementation of the Resolver interface should also have a set of unit tests.
add088b to
6e40d8f
Compare
6e40d8f to
87e99cf
Compare
stevekuznetsov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking really good! Let's add unit tests for Resolve, add in the call to use the resolver in CI Operator and I think we are close to done!
The unit test could look something like:
func TestResolve(t *testing.T) {
var testCases = []struct{
name string
input api.MultiStageTestConfiguration
expected types.TestFlow
expectedError bool
} {
name: ""
// ...
}
for _, testCase := range testCases {
t.Run(testCase.name, func(t *testing.T) {
actual, err := NewResolver().Resolve(testCase.input)
// check things
}
}
}
stevekuznetsov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we need a set of unit tests for the Resolve() method like I mentioned in the last review. Otherwise, this looks good!
stevekuznetsov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the typo that Petr noticed, this is ready to merge!
62025c5 to
c0a455a
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: AlexNPavel, stevekuznetsov The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This implements a few new structs to allow us to read in user test configs and a function to expand the user's config (which may contain references, chains, etc) into a full internal test representation. This contains some duplicate code from
TestStepConfigurationas this is essentially the evolution of that struct, but I did not want to trample that code while this new config format is still in a WIP state./cc @stevekuznetsov @bbguimaraes