[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:

https://github.com/gradle/gradle/pull/190

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
Scenario: Say hello /two/three
Given I have a hello app with Howdy and /four
When I ask it to say hi and /five/six/seven
Then it should answer with Howdy World

Generated at Wed Jun 30 12:30:10 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.