Provide unique IDs for all node info objects

[Vampire]

No description provided.

[Vampire]

• Provide unique IDs for all node info objects #1696 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.89%. Comparing base (f350b52) to head (92d0a32).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1696      +/-   ##
============================================
- Coverage     81.92%   81.89%   -0.03%     
- Complexity     4687     4688       +1     
============================================
  Files           452      452              
  Lines         14678    14685       +7     
  Branches       1847     1847              
============================================
+ Hits          12025    12027       +2     
- Misses         1972     1976       +4     
- Partials        681      682       +1     

Files with missing lines	Coverage Δ
...va/org/spockframework/runtime/SpecInfoBuilder.java	99.27% <100.00%> (+0.01%)	⬆️
...rg/spockframework/runtime/model/IterationInfo.java	95.45% <100.00%> (+0.21%)	⬆️
...ava/org/spockframework/runtime/model/NodeInfo.java	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[leonard84]

What is the use-case? And shouldn't we have something that is stable across invocations, otherwise it's use is severely limited.

[Vampire]

What is the use-case?

Well, everytime you need a unique ID during the test.
One use-case where I needed it is for example to put it as thread context map entry to log messages, so that you can identify log messages belonging to an iteration and test logging behavior in a multi-threaded SUT.

And shouldn't we have something that is stable across invocations, otherwise it's use is severely limited.

Well, the intended use by me was during one test run to relate things, without needing to build a unique ID yourself.
And for spec info, feature info and iteration info, it actually is stable across invocations, just not for "other" nodes.
Others being data provider info, field info, method info and parameter info.

Not sure whether we need stable unique ids for those. :-/

[Vampire]

Also, that they are stable across invocations for spec, feature, and iteration info is mainly a side-effect. The goal was to have something descriptive that can the also easily be readable for example in the log output where I intend to use it. :-D

[leonard84]

Given that we now have the extension store, do you still see a need?
IMHO, it is too niche to be added to spock-core.

[Vampire]

I don't know how this is in any way related to the extension store.
The extension store provides a place to put things at.
This provides a unique ID identifying a spec / a feature / an interation / ...
They don't really have anything in common, unless you use the ID as a key for a map, but then you could also just use the node itself as key.

So yes, I still see the need and imho it is not really niche or I wouldn't have created a PR.
But if you don't agree, we can of course also close this, not a problem for me, everyone that needs it can generate such an id theirselves.