Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New support for sequenced stub actions implemented. #49

Closed
wants to merge 3 commits into from

Conversation

shamoh
Copy link
Contributor

@shamoh shamoh commented May 6, 2016

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

shamoh added 2 commits May 6, 2016
Fixing guide links and formatting.
Updated version of Grizzly dependency to the latest v2.3.24.
@martinjmares
Copy link

martinjmares commented May 9, 2016

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

@shamoh
Copy link
Contributor Author

shamoh commented May 9, 2016

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

.then().assertThat().body(equalTo("UPDATED VALUE"));
}

}
Copy link
Owner

@mkotsur mkotsur May 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@shamoh shamoh May 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner

@mkotsur mkotsur May 10, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@shamoh shamoh May 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, I hope. ;)

Copy link
Owner

@mkotsur mkotsur May 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mkotsur
Copy link
Owner

mkotsur commented May 9, 2016

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
Copy link
Owner

mkotsur commented May 14, 2016

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
Copy link
Contributor Author

shamoh commented May 15, 2016

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

@mkotsur
Copy link
Owner

mkotsur commented May 15, 2016

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

@shamoh
Copy link
Contributor Author

shamoh commented May 16, 2016

Yes, we are on Java 8.

@mkotsur
Copy link
Owner

mkotsur commented May 28, 2016

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
Copy link
Owner

mkotsur commented Sep 28, 2016

The feature has been released and available in 0.9.0.

@mkotsur mkotsur closed this Sep 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants