spock
spock copied to clipboard
spockframework
Derived data provider
Where block elements lack consistency in many cases, e.g.:
- derived parameterizations (
b = a + 1) aren't data providers - data providers cannot refer to their value
- data providers cannot refer to previous data providers in a closure etc.
To make these possible in the future (but even if not), many affected classes and tests were refactored and provided with comments.
Also, @PendingFeature tests were added to demonstrate the inconsistent behavior.
This commit does not fix these issues, as they proved to be far to complex for a single commit.
Please review the commits separately.
This change is 
Since this PR reformats the SourceCode extensively I would wait for #555 to be implemented.
Hey @leonard84, would it make sense for me to rebase this PR or should we close it?
@paplorinc I'll have to look at this after we merge the spock-2.0 branch, before this it doesn't make sense to invest any work.
@paplorinc many things in this area changed over the last versions with PRs from me. Would you mind checking with current state whether your changes might still be relevant or not?
Derived Datavariables are still no data providers, but I think they don't need to be anymore. That you previously could to a certain degree access previous data variables in later data pipes was actually mainly a side-effect of making it possible to access previous columns in data tables.
Accessing previous data variables in later data pipes had many quirks and issues. If I remember correctly, I tried to fix them but in the end came to the conclusion that it is not worth it or not possible. So in 2.0 we made a breaking change and now forbid accessing other data variables due to all the problems and quirks like you could easily prematurely drain iterators, access data providers sooner as expected, behaved differently depending on the concrete code construct used, .... All these points were more confusing than necessary, so we forbid it and now you can only access previous columns in data tables (even across tables in the same where block) or all previous data variables in derived data variables.
So at least now it should behave consistent, even if some accidentally half-available functionality was removed.
