Updated CategoryFilter to prevent NPE with Cucumber and JUnit Categories #1511
Conversation
- NullPointerException was being thrown if JUnit Categories were used in a project containing Cucumber tests. - Ensure CategoryFilter does not call createSuiteDescription if the description test class is null - Added integration test to reproduce the error
|
|
||
| test { | ||
| useJUnit { | ||
| excludeCategories 'CategoryA' |
There was a problem hiding this comment.
What's the relevance of this category if it is excluded anyway?
There was a problem hiding this comment.
CategoryFilter, the source of the bug, is only invoked if a category inclusion / exclusion is specified here. It doesn't matter what is excluded. In fact, no test is even annotated with this category.
| public class DescriptionWithNullClassTest { | ||
|
|
||
| @Test | ||
| public void someTest() throws Exception { |
There was a problem hiding this comment.
Doesn't need to throw an exception.
|
|
||
| @Test | ||
| public void someTest() throws Exception { | ||
|
|
There was a problem hiding this comment.
Please remove the unnecessary new lines.
| @@ -64,4 +64,16 @@ public class JUnitCategoriesIntegrationSpec extends AbstractIntegrationSpec { | |||
| def result = new DefaultTestExecutionResult(testDirectory) | |||
| result.testClass("org.gradle.SomeTest").assertTestFailed("initializationError", startsWith("org.gradle.api.GradleException: JUnit Categories defined but declared JUnit version does not support Categories.")) | |||
| } | |||
|
|
|||
| def supportsCategoriesAndNullTestClassDescription() { | |||
| when: | |||
There was a problem hiding this comment.
Can you please a new line between when and then?
| run "test" | ||
| then: | ||
| ":test" in nonSkippedTasks | ||
| and: |
There was a problem hiding this comment.
Let's remove the last and statement. It's OK to just have this under then.
|
Thanks for the pull request. It has been merged! |
|
Awesome, thanks! |
|
Sure thing. Sorry about the long wait. |
Fix for #1510
This bug was originally reported by @krosenvold on the Gradle Forum.
Any of the checked boxes below indicate that I took action:
./gradlew quickCheckFor all non-trivial changes that modify the behavior or public API:
the forum or can reference a JIRA issue.
brief but explains the use case or problem you are trying to solve,
touches on the planned implementation approach as well as the test cases
that verify the behavior. Optimally, design documents should be submitted
as a separate pull request. Samples
can be found in the Gradle GitHub repository. Please let us know if you need help with
creating the design document. We are happy to help!
test coverage to verify the behavior. Before submitting the pull request
I ran a build on my local machine via the command
./gradlew quickCheck <impacted-subproject>:check.DSL reference and Javadocs where applicable.