-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
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
Use isEmpty()
and simplified assertions in Test
#8473
Use isEmpty()
and simplified assertions in Test
#8473
Conversation
This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. |
@@ -487,7 +487,7 @@ private String callDependerValue() throws Exception { | |||
// Check that the basic API endpoint invocation works. | |||
assertEquals("ok", response.getString("status")); | |||
JSONArray data = response.getJSONArray("data"); | |||
assertTrue(data.size() > 0); | |||
assertFalse(data.isEmpty()); |
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.
both of these are not great - if it fails it does not give you hints as to why it fails - what was in the data is a great hint for analysis.
E.g.
assertThat(data, empty())
would be preferable here as it would produce something like expected an empty collection but got ["some", "Collection", "with", "values"]
(hamcrest javadoc, other asserts libraries also available)
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.
y'all should have bashed me over the head.
as this would only fail if the collection was empty there is no additional information to be gleaned in this case. An empty collection is an empty collection no matter what diagnostics you add.
The inverse (when checking it is empty) is not the case - but these where asserting something was not empty, not that it was empty.
My apologies @StefanSpieker
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 guess we all got a little confused :) But now it is really better than before :)
@StefanSpieker Would you mind addressing the feedback from jtnord? |
something is not empty (and we have some info about it)! https://github.com/jenkinsci/jenkins/pull/8473/checks?check_run_id=16857757226 |
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
Co-authored-by: James Nord <[email protected]>
/label ready-for-merge |
I wasn't able to add the following labels: ready Check that the label exists and is spelt right then try again. |
/label ready-for-merge |
Use
isEmpty()
and simplified assertions in TestTesting done
Unit Tests still pass locally
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
@Restricted
or have@since TODO
Javadocs, as appropriate.@Deprecated(since = "TODO")
or@Deprecated(forRemoval = true, since = "TODO")
, if applicable.eval
to ease future introduction of Content Security Policy (CSP) directives (see documentation).Desired reviewers
Before the changes are marked as
ready-for-merge
:Maintainer checklist
upgrade-guide-needed
label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).lts-candidate
to be considered (see query).