-
Notifications
You must be signed in to change notification settings - Fork 705
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
[kubeops] Add tests for GetRelease #1434
[kubeops] Add tests for GetRelease #1434
Conversation
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.
Thanks for adding the tests @latiif! I have a few of small suggestions
}, | ||
}, | ||
}, | ||
Helm2Release: h2.Release{ |
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.
shouldn't this be empty if it fails?
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.
Making the Helm2Release
would make it fail, sure.
Here we test that all other information are identical, except for the version.
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 see. The thing I was missing is that the function never fails (I doesn't return an error) so the ShouldFail
param is a bit misleading. Actually this test is not testing any functional code. As far as I can see, you are giving a wrong expected result and verifying that the test is "failing" (so this is more a test for the test).
If I am correct with the above, I suggest to remove this test and remove the ShouldFail
param for this to be more readable. Also, I would make it so all the Helm2Releases are equals to whatever we set in the test. That way, if both releases are not equal, we know exactly how it should behave in that case. I am talking about the next test: Incomplete Helm 3 Release
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.
You are correct. I will remove it. Thanks for pointing it out.
} | ||
} | ||
|
||
func asResponse(data h2.Release) string { |
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.
can you explain why you are using asResponse
? Why not using directly a marshall function?
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.
still not sure about this ^
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.
In the current setting, the result from the function newDashboardCompatibleRelease
is used in kubeops/internal/handler
here & here, which both marshal the data using github.com/unrolled/render
. To avoid digging in the aforementioned library and to enable further tests where newDashboardCompatibleRelease
are marshalled/viewed in different ways, I created asResponse
as a helper function to mimic the behaviour in /cmd/kubeops/internal/handler/handler.go
.
If my reasoning seems too stretched I can just bake it into the test.
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.
That's fine, a comment explaining that would be helpful for the future
Description string | ||
Helm3Release h3.Release | ||
Helm2Release h2.Release | ||
MarshallingFunction func(h2.Release) string |
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 always asResponse
, in which case you plan to change this function?
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.
If we add a test scenario where we test newDashboardCompatibleRelease
against for example spew.Sdump
, or a hand-written one where for example not all fields are relevant/populated etc.
// TODO Remove this `if` statement after the memory driver bug is fixed | ||
if test.StatusCode == 404 && response.Code == 500 { | ||
t.SkipNow() | ||
} |
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 bit difficult to notice, I would rather add a field "skip: bool" to the test struct and explicitly mark some tests to be skipped (and add a link to the Github issue that should be fixed)
229ff47
to
a070277
Compare
- Add test for GetRelease in /pkg/agent - Add 'action=get' tests for /kubeops/handler - Add tests for 'dashboardcompat.go' in /kubeops/handler - Replace newConfigFixture with newActionConfigFixture - Skip tests blocked by memory driver bug TODO: REMOVE CHANGES FROM THIS COMMIT WHEN MEMORY DRIVER IS FIXED Signed-off-by: Latiif <abdullatif.alshriaf@combitech.se>
efd508f
to
5d1511a
Compare
- Remove non-functionality-testing tests. - Remove 'shouldFail' flag. - Capture panics and report them within the test suite. Signed-off-by: Latiif <abdullatif.alshriaf@combitech.se>
Signed-off-by: Latiif <abdullatif.alshriaf@combitech.se>
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.
Thanks for the changes!
Signed-off-by: Latiif <abdullatif.alshriaf@combitech.se>
Comment added for:
For further improvements or tests on the |
|
||
for _, test := range tests { | ||
t.Run(test.Description, func(t *testing.T) { | ||
// Capture the panic and report it in an orderly fashion |
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'm confused as to why we're handling a panic that we've discovered in tests, rather than removing the panic from the code? What causes the panic... if I run these tests without the panic handling, it just succeeds.
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 came back to this later today, found the cause of the panic, added some failing tests and fixed. See what you think: #1445
Description of the change
Tests new functionality introduced by #1406 .
Benefits
/pkg/agent
action="get"
tests for/kubeops/handler
dashboardcompat.go
in/kubeops/internal/handler
Possible drawbacks
Skip tests blocked by memory driver bug
Applicable issues
Tests #1406
Additional information
Contains a
TODO
in/cmd/kubeops/internal/handler/handler_test.go
with instructions on what to do when the memory driver bug is fixed.Signed-off-by: Latiif abdullatif.alshriaf@combitech.se