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

Reset/Clear RequestContext Values #24

Open
dcrissman opened this issue Oct 1, 2012 · 8 comments
Open

Reset/Clear RequestContext Values #24

dcrissman opened this issue Oct 1, 2012 · 8 comments

Comments

@dcrissman
Copy link

Currently various Objects can be added to the RequestContext, but then there is no way to make changes later.

Say you wanted to change out or remove an Authentication or Path Segment.

@dcrissman
Copy link
Author

My initial thought was to add a simple method to the Destination that would create a new instance of RequestContext. But now I am not sure that is the best way. Open to suggestions...

Example:
public void resetRequestContext(){
this.context = new RequestContext();
}

@hstaudacher
Copy link

I thought about this since the last week and came to the conclusion that the RequestContext is the problem. Let me explain this:

The limitations of the RequestContext is obvious. I came up with an idea that goes beyond the RequestContext. I call it "Test Method Chaining". We need a configuration that can change between two test method calls. This would be also good to extract links from responses and call those links in the next test method (HyperMedia Linking). I need to think more in detail about this to come up with a design how this can look like. But I want to implement this within the next weeks. The drawback about this approach is that their would be a relation between test methods. While this is bad for unit tests I think it's not a problem for integration tests because they should test the whole system. What do you think?

I hope I coud make it clear. Don't hesitate to ask if my explanation is scrappy ;)

@dcrissman
Copy link
Author

The concept sounds good.

When I first saw #17 even, I had sort of had the same feeling that unit tests should be independent of each-other (and generally they should be), but the more I thought about it for REST integration testing, the more I came to the same conclusion that being able to control order of execution and the relationships between various tests could be very useful. That said, I would still want the unit tests to be as independent as possible.

I would be interested to know more as the design takes form. Let me know if I can be of any help.

@dcrissman
Copy link
Author

Any updates on this?

I would be glad to assist if you need a hand.

@hstaudacher
Copy link

Will work on this during the weekend and next week. Will keep you posted.

@sergiopino
Copy link

Hi,
I think this will solve the header issue as well.
When you start a unit test it takes the default Accept value in the header.
If in one unit test you try to force it to another value it just doesn't work.
Can you please check this as well.
SP

@hstaudacher
Copy link

Couldn't make it on the weekend. But I fixed other issues ;).

I'm on a conference next weeks which needs preparation this week, so less time ;(

Will try to work on this next. Will keep you posted.

@dcrissman
Copy link
Author

Just curious if you have any more details about your "Test Method Chaining"? I am very curious about what you have in mind.

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

No branches or pull requests

3 participants