Skip to content
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

Merged
merged 5 commits into from
Jan 13, 2020

Conversation

latiif
Copy link
Contributor

@latiif latiif commented Jan 10, 2020

Description of the change

Tests new functionality introduced by #1406 .

Benefits

  • Adds test for GetRelease in /pkg/agent
  • Adds action="get" tests for /kubeops/handler
  • Adds tests for 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

Copy link
Contributor

@andresmgot andresmgot left a 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{
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@andresmgot andresmgot Jan 13, 2020

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

Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor

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 ^

Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Comment on lines 187 to 190
// TODO Remove this `if` statement after the memory driver bug is fixed
if test.StatusCode == 404 && response.Code == 500 {
t.SkipNow()
}
Copy link
Contributor

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)

@latiif latiif force-pushed the test-helm3-get-release branch from 229ff47 to a070277 Compare January 11, 2020 09:43
- 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>
@latiif latiif force-pushed the test-helm3-get-release branch from efd508f to 5d1511a Compare January 12, 2020 17:05
- 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>
Copy link
Contributor

@andresmgot andresmgot left a 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>
@latiif
Copy link
Contributor Author

latiif commented Jan 13, 2020

Comment added for:

  • The field MarshallingFunction
  • The function asResponse

For further improvements or tests on the dashboardcompat.go

@andresmgot andresmgot merged commit ac689ce into vmware-tanzu:master Jan 13, 2020

for _, test := range tests {
t.Run(test.Description, func(t *testing.T) {
// Capture the panic and report it in an orderly fashion
Copy link
Contributor

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.

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants