-
Notifications
You must be signed in to change notification settings - Fork 81
implement approval conditioned on issue severities #141
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,6 @@ | ||
package org.sonar.plugins.stash; | ||
|
||
import java.util.Optional; | ||
import org.junit.Before; | ||
import org.junit.Test; | ||
import org.junit.runner.RunWith; | ||
|
@@ -9,7 +10,9 @@ | |
import org.sonar.api.batch.SensorContext; | ||
import org.sonar.api.issue.Issue; | ||
import org.sonar.api.issue.ProjectIssues; | ||
import org.sonar.api.issue.internal.DefaultIssue; | ||
import org.sonar.api.resources.Project; | ||
import org.sonar.api.rule.Severity; | ||
import org.sonar.plugins.stash.client.StashClient; | ||
import org.sonar.plugins.stash.client.StashCredentials; | ||
import org.sonar.plugins.stash.coverage.CoverageProjectStore; | ||
|
@@ -19,6 +22,8 @@ | |
import java.util.ArrayList; | ||
import java.util.List; | ||
|
||
import static org.junit.Assert.assertFalse; | ||
import static org.junit.Assert.assertTrue; | ||
import static org.mockito.Matchers.eq; | ||
import static org.mockito.Mockito.spy; | ||
import static org.mockito.Mockito.times; | ||
|
@@ -247,6 +252,36 @@ public void testExecuteOnWithNoDiffReport() throws Exception { | |
verify(stashRequestFacade, times(0)).resetPullRequestApproval(eq(pr), (StashClient)Mockito.anyObject()); | ||
} | ||
|
||
@Test | ||
public void testShouldApprovePullRequest() { | ||
Issue minorIssue = new DefaultIssue().setSeverity(Severity.MINOR); | ||
Issue majorIssue = new DefaultIssue().setSeverity(Severity.MAJOR); | ||
|
||
report = new ArrayList<>(); | ||
|
||
report.add(minorIssue); | ||
report.add(majorIssue); | ||
|
||
assertFalse( | ||
StashIssueReportingPostJob.shouldApprovePullRequest(Optional.empty(), report) | ||
); | ||
|
||
report.clear(); | ||
assertTrue( | ||
StashIssueReportingPostJob.shouldApprovePullRequest(Optional.empty(), report) | ||
); | ||
|
||
report.add(minorIssue); | ||
assertTrue( | ||
StashIssueReportingPostJob.shouldApprovePullRequest(Optional.of(Severity.MINOR), report) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As far as I can see, shouldApprovePullRequest is an internal method, that is implementation details. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The method is made a package-scoped static method especially to improve testing. |
||
); | ||
|
||
report.add(majorIssue); | ||
assertFalse( | ||
StashIssueReportingPostJob.shouldApprovePullRequest(Optional.of(Severity.MINOR), report) | ||
); | ||
} | ||
|
||
/* FIXME | ||
@Test | ||
public void testExecuteOnWithPullRequestApprovalAndNoNewIssueAndCodeCoverageEvolutionPositive() throws Exception { | ||
|
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.
multiple asserts in a single test method are considered a test smell
It is often better to split such a test method into separate cases. One can give those separate test method meathingful names and do a proper setup in those smaller methods
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 general I agree with this being a smell.
However as far as I know this is a concern when testing objects with (complex) internal state.
So when doing multiple asserts the later ones may depend on implicitly changed state in the object.
As the tested functionality here is only a single static method there is no state.
Furthermore by doing it this way if some assertion failed is immediately obvious how this assertion differed from the previous one.
If there are multiple test functions all doing essentially the same setup (only progressing) then I first have to compare all the test methods where the actual differences are.
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.
The test with multiple asserts might fail at first assertion and other assertions are not executed at all.
It is good when one break makes only one assert fail, letting other asserts be executed in separate test methods.
As soon as you break test code to separate tests, you have a problem of repetitous setup. It is solved easily by single
@Before
method or a helper method called in each method.If the assert should be checked only after some other checks have succeeded (which are checked in separate test methods) then one can use
assume*
methods of JUnit.As soon as you have your tests split this way, single defect breaks one test only. Some other tests may become yellow telling you the defect is essential for checks performed there. The good thing you'd know what have failed exactly. If several things have failed you'd know all of them.
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 totally agree with you if the object under test is complex and contains internal state. However for a static method I think it is overkill. I very much prefer a simple test execution where I can see the difference of the parameters between the assertions very easily.
It would be even better to have nice parameterized tests in Java like in python, but in Junit this involves a ridiculous amount of boilerplate hiding the actual logic.
Can we agree to disagree on this one with me (ab)using my maintainer powers to keep the status quo?