Provide unique IDs for all node info objects

[Vampire]

No description provided.

[Vampire]

• Provide unique IDs for all node info objects #1696 👈
• master

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

Join @Vampire and the rest of your teammates on Graphite

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.18%. Comparing base (2c7db77) to head (f918dea).
Report is 96 commits behind head on master.

❗ Current head f918dea differs from pull request most recent head 9bffe3b

Please upload reports for the commit 9bffe3b to get more accurate results.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1696      +/-   ##
============================================
- Coverage     80.44%   80.18%   -0.27%     
+ Complexity     4337     4299      -38     
============================================
  Files           441      439       -2     
  Lines         13534    13481      -53     
  Branches       1707     1701       -6     
============================================
- Hits          10888    10810      -78     
- Misses         2008     2026      +18     
- Partials        638      645       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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

With the current code you could easily externalize it to a helper function. I don't see a strong reason to add it to the API and only see potential problems when we'll add #1153.

[Vampire]

I don't see where there should be problems with #1153.
You probably have a "spec iteration index" for data-driven specs and can attach that to the spec unique id like for feature iterations.
Or there will maybe be a SpecIterationInfo for data driven specs.
However it will look, I'd expect it to be trivial to maintain unique ids still.

Of course the code can also be written in any project that needs such an ID.
I currently use

public static String getIterationIdentifier(IterationInfo iterationInfo) {
    FeatureInfo featureInfo = iterationInfo.getParent();
    SpecInfo specInfo = featureInfo.getParent();

    return new StringJoiner(".")
            .add(specInfo.getReflection().getName())
            .add(featureInfo.getFeatureMethod().getReflection().getName())
            .add(String.valueOf(iterationInfo.getIterationIndex()))
            .toString();
}

But I thought it would be nice to provide ready-made values already for such use-cases.

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