[GRADLE-2739] Cucumber test report file formation is failing in Gradle 1.5 Created: 08/Apr/13 Updated: 14/Oct/13 Resolved: 15/Sep/13 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.5 |
Fix Version/s: | 1.9-rc-1 |
Type: | Bug | ||
Reporter: | Gradle Forums | Assignee: | Luke Daley |
Resolution: | Fixed | Votes: | 2 |
Description |
See linked forum post. Example project that exhibits failure can be found at: https://github.com/ae6rt/cucumberjvm-gradle14 |
Comments |
Comment by mark petrovic [ 08/May/13 ] |
In case it's not clear, I have a cucumber JVM Scenario that reads like this: Scenario: FX cache clearing for /fx endpoint The "/" in "/fx" is being interpreted as a Java file path separator, which is semantically incorrect. The "/" should be escaped before the filename/directoryName that will hold the test results is formed. I took a look in org.gradle.api.internal.tasks.testing.junit.result.CachingFileWriter#write for where the exception is thrown for Scenarios with "/" in their description. Unfortunately, but this time it's too late to determine which "/" in the test output file name should be escaped. This escaping has to be performed at the earliest point in time when the test file name is undergoing formation. Only then can you make a determination that "/" should be escaped. Finally, even if this escaping is performed, one will still encounter the bug in http://issues.gradle.org/browse/GRADLE-2765 which in my case is triggered when the report for the Scenario "header" itself is undergoing formation. Reports for the subsequent Given/When/Then succeed – or at least do not throw exceptions. I'm not sure what succeed even means at the level of Given/When/Then, but that's another matter. |
Comment by mark petrovic [ 04/Sep/13 ] |
I have a pull request that may help with this: |
Comment by Luke Daley [ 05/Sep/13 ] |
This is inadvertently fixed in 1.8 as we no longer use a file per test case for storing output but use one file with a constant name. We just need some int test coverage for these kinds of cucumber tests to prove it and then we can close. |
Comment by mark petrovic [ 06/Sep/13 ] |
I'm not sure where to put this, so I'll just continue to put facts like this here. I have a test that demonstrates the fix, but that's not specifically what this comment is about. As I delve further into how Cucumber reports, or how Gradle derives - not sure which, test class names and method names, I first observe this on stdout: RunCukesTest > Scenario: Say hello /two/three.null STARTED Note the ".null". I'll repeat this here, but I think we already know what is going on here in the context of this currently-benign reference to a null variable: The Scenario clause is being interpreted as the test class name, and the step def is being interpreted as the test method name. So when this test descriptor is instantiated org.gradle.api.internal.tasks.testing.DefaultTestDescriptor#DefaultTestDescriptor the ctor className variable is not null, but the next ctor argument "name" is. Here is more data: a START event with className not null and name not null, which corresponds to the execution of a step def: RunCukesTest > Scenario: Say hello /two/three.Given I have a hello app with Howdy and /four STARTED Here is the effective feature file that backs these observations: Feature: Hello World /one @bar |