Add Test Case UUID to Scenario Object

[GregJohnStewart]

I am currently generating an ID at the beginning of every test that I use for logging and other test identification. I do this during a before() hook where I can interact with other data objects presented via picocontainer. I noticed that Cucumber also creates a UUID for a "TestCase". I'm not personally read into the differences between a TestCase and a Scenario, but it would be great to have access to that UUID as part of the Scenario object in order to have the id that cucumber already generates and uses.

I have seen that the Scenario object has an id associated with it, but it seems to be a longer string outlining the file, etc that the test comes from that is not as useful as a quick ID number

[mpkorstanje]

A test case is an instance of an execution of a scenario or an example in a scenario outline.

The scenario id is defined as the uri of the scenario appended with a line number. This identifies the scenario in a (relatively) stable manner across different executions where as the TestCase.testExecutionId is unique per execution.

What would you use the execution id for?

[GregJohnStewart]

Sure, currently we are using a short 8-character identifier that we generate at the beginning of the test in a @Before that is used throughout the test for identification purposes. This id is attached in the scenario output, and used as a marker for logging so we can search for that marker through the log files, among other useful identification purposes (we store this id in a shared data object supplied to all step definition classes by PicoContainer).

We generate this id by:

1. Concatenate the scenario name, tags, and id into one string
2. Take the SHA-512 hash of the string
3. Take the first 8 characters of this hash as the ID

The goal here being to get a unique identifier for a particular test that is also conveniently used where a longer string would be obnoxious (log markers, test file names, test usernames, etc). We also keep our scenario names distinct even across examples, alleviating concerns of duplicates. IMO, if a test was rerun and had the same ID I would be okay with that as well. I am also not stating that this approach is perfect, it seems to work as intended for us so far.

I am fine with us using this, but when I came across the UUID that was part of the TestCase object, I felt there was some duplication of effort and it would be nice to use an ID that was already supplied, rather than create our own. If the same id was used across the board, then it would mean better traceability as well.

To be specific, we just switched to running our tests in parallel, and we wanted to output something while the threads were running in the background (so the tests would not appear hung). We landed on using a custom EventHandler<TestCaseFinished> to output when a test finished in one of the threads (since this is handled in the main thread, we can see the output as it happens, rather than after all tests complete). It is here that we stumbled upon the UUID provided by Cucumber, which is of course separate from what we generate. I was thinking it would be nice to be able to output a matching ID at this handler to this event.

I am not necessarily asking that the UUID is changed to a different format either, we could simply use the first grouping of the UUID for our internal "short id" needs. Just saying that it would be nice to have access to the ID that Cucumber already generates from a step definition class. I might think that access to the TestCase object from here (step definition classes) or even have a reference to it from the Scenario object would be sufficient.

If we are willing to change from the UUID, I might recommend a similar approach to what we have implemented; generate a sha, take the first n bits, and append a number for the mth time that particular test has run (for a unique identifier between runs).

Just tossing ideas out!

[GregJohnStewart]

@mpkorstanje Bump, since it has been a while. Let me know if anything needs clarification!

[mpkorstanje]

Currently short on time and prioritizing the release of v7.0.0. No need to bump.

[mpkorstanje]

There is definitely a mismatch between Scenario.getId() and TestCase.getId() and I think the best way to resolve this conflict would be to make Scenario.getId() return the same value as TestCase.getId(). The old representation can still be obtained by combining the scenarios uri and line together.

[mpkorstanje]

This is breaking change so it'd have to go into v7.