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.91%. Comparing base (a602687) to head (f0ce472).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1696      +/-   ##
============================================
+ Coverage     81.89%   81.91%   +0.01%     
  Complexity     4734     4734              
============================================
  Files           463      463              
  Lines         14767    14774       +7     
  Branches       1869     1869              
============================================
+ Hits          12094    12102       +8     
  Misses         1981     1981              
+ Partials        692      691       -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 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[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