smartrics/RestFixture — pull request #38 by lachelt (2012-10-15 18:32:30+00:00)
Title: Enhancement to "ignore timeouts"

We wanted to write some functional tests that verify the behavior of our API in the face of concurrent requests to update the same resource.

In our implementation we lock the resource such that other GET/POST/PUT requests will fail with a 409 because the resource is locked.

To test that this locking is behaving correctly we thought of this sort of RestFixture scenario...

The key is that we need to have Fitnesse issue two REST calls "concurrently". So we simulate "concurrently" in the following way...

1) make a POST to change the state of resource X
a. using a configuration with http.client.connection.timeout=500ms
b. we use some hidden behavior in our resource implementation that causes this request
to take a few seconds
c. we would expect this RestFixture row to timeout... but we don't want this to be counted
as an error or an exception
d. this row doesn't check the response code or the response body (since we expect it to timeout)
2) make another POST to resource X
a. the test expects this to get an 409 (because the resource is locked)
3) wait a few seconds
4) make a GET request to see that the initial POST actually completed its work as expected

To enable this kind of test, the enhancement in this commit is three-fold:

1) add a new configuration parameter:

restfixture.ignore.read.timeout (boolean true | false)

2) make the code in the RestFixture.doMethod() be aware of this flag and if we see a timeout then ignore it

3) add a sleep() method so that we can easily do a sleep in our test (step #3 above).

======================
I'm afraid that this commit also includes a couple of other things that you don't want.
1) change to the pom file so that I could get the fixture to build
2) make the RestFixture extend fit.Fixture
I couldn't get the fixture to work in Fitnesse without that. There's probably something I'm doing
incorrectly
3) changes to comment out the setHeader substitution because Fitnesse was counting those as
"wrong assertions"

======
I'm sure that my hack to make the code ignore timeouts could be done more elegantly... so if you see a better way to do it please feel free to fix it.

I'm afraid I didn't write any unit tests for this functionality. I'm not sure how I would test that kind of timeout handling in junit.

I'm happy to discuss this enhancement it you want to understand our motivation.