This has been bugging me enough to just rage post.
Why does StoryQ not have a truly fluent interface?
What do I mean by this?
All of the given when then seem to follow after each other.. so that's fluent right?
Well no, not if the parameters that are passed into the method are evaluated once at runtime, and not when they execute individually.
There is no delayed execution.. Which quite frankly means you have to resort to an unwanted pattern of using it with private parameters behind the scenes and only pass in instantiated variables or hard coded ones into the methods.. which quite frankly sucks.
Is it that much harder to have a lazily executed style like LINQ? With the parameters only being evaluated when that method itself executes.
So to be absolutely clear:
Any modifications made to an object inside one of the methods in StoryQ "Fluent" interface, is not reflected in the execution of the next method, if the object is passed into the method as a parameter.
However the object has been modified and if I debug the test I can see that the state of the object has changed.
StoryQ appears to only use the state of the object at the start of the test. Meaning that any updates to the object are not reflected in tests that follow the execution of the first method in the StoryQ Interace.
Is this intended?
Because it really seems like it limits the way StoryQ is supposed to work in my opinion.
Maybe I'm just an idiot and am missing something very obvious.
If I am please point this out.
I guess a question would be why would this style be important and why would I care?
During the course of building up a series of "BDD" style tests, you inevitably have similar setup or scenarios that crop up again and again. What I want to achieve is a nice way to progress through these various scenarios and their commonalities with
a fluent interface that encapsulates the functionality and allows to flow through a series of tasks that a user might perform.
Using the private variables route that works fine if you never need to do any sort of testing for parallel execution and race conditions, then it starts to get tricky and quite messy. It is possible but ugly and messy in my opinion.