New support for sequenced stub actions implemented.

[shamoh]

Hi Mike.

This is suggestion how to extend Action API to support different response for identical requests repeated in sequence.

Let me know if you like the idea or if you prefer to make it different way.

Thanks,
Libor

[martinjmares]

I am supporting this idea! +1 for this pull request.
(I also like small fixes in documentation, which are included in the change.)

[shamoh]

My blog post about this feature: http://yatel.kramolis.cz/2016/05/restito-sequenced-stub-action.html

[mkotsur]

I would like to add a test with at least two different conditions to make sure that the state is not thrown away when another condition kicks in.

[shamoh]

I have no problem to add another tests. But to be honest I don't know what you mean by "the state is not thrown away when another condition kicks in". Could describe little bit more verbose test steps? Thanks.

[mkotsur]

Oh, I just mean:

Setup:

When /foo
Then OK200 and sequence STRINGfoo1, STRINfoo2

When /bar
Then OK200 and sequence STRINGbar1, STRINGbar2, STRINGbar3

Checks:

Get /foo expect STRINGfoo1
Get /bar expect STRINGbar1
Get /foo expect STRINGfoo2
...

And so on...

[shamoh]

Done, I hope. ;)

[mkotsur]

Thanks, looks good. I think it is important to cover this case.

[mkotsur]

Thanks a lot for the pull request. This is the biggest one so far!👋 I definitely think that thefeature is very useful, and restito needs it.

Please take a look at the comments and let me know what you think.

Btw, I am writing from the phone now, will get back to 💻 in a few days, please be patient :-)

[mkotsur]

I've been thinking about this for couple of days, and then finally got back to the laptop, and could hack a little bit. The main concern now is that by keeping the queue inside the action object, we overload this (originally) very lightweight, well-composable and stateless concept.

This, for instance is perfectly fine now, but will become unsafe (because a may contain state, and requests to /bar will influence the action passed for /foo as well):

Action a = //something

whenHttp(server).match(get("/bar")).then(a);
whenHttp(server).match(get("/foo")).then(a);

How to avoid this? Keep configuration objects stateless, and push the state into higher-level concepts (like Stub, which already have appliedTimes, expectedTimes counters, thus can't be reused across requests, or to the StubServer, which holds the list of stubs).

I'm now doing some refactoring within Stubs-related code, based on your PR. It's still WIP, few tests fail, hope to finish it tomorrow to see how it looks in the end. Care to take a look?

https://github.com/mkotsur/restito/compare/shamoh-sequenced-stub-actions

[shamoh]

@mkotsur Ok, let me know if I can help.

[mkotsur]

@shamoh @martinjmares are you guys using restito with Java8? I'm thinking about dropping 7 support. Is this fine for you?

[shamoh]

Yes, we are on Java 8.

[mkotsur]

Created another pull request (#50) based on these changes. I guess, I don't have permissions to commit to this fork, that's why.

[mkotsur]

The feature has been released and available in 0.9.0.