Rest-assured: Support baseURL/port setting for parallel testing

[johanhaleby]

_From [email protected] on December 15, 2014 10:43:19_

What steps will reproduce the problem? 1. Set RestAssured.baseURL and RestAssured.port in a @BeforeClass

1. Have multiple tests using different baseURLs/ports but without specifying on each rest-assured invocation
2. Running tests in sequence work as expected
3. Running tests in parallel fail as baseURLs and ports are statics

So, the issue here is that as baseURLs and port are statics, running tests in parallel mix them up.
This is how things should work.

But, what would you propose in order to be able to run tests in parallel without specifying baseURL & port on each rest-assured invocation ?

I see nasty ThreadLocals ... but maybe you could suggest something else I haven't tought about.

Loving rest-assured BTW :)

_Original issue: http://code.google.com/p/rest-assured/issues/detail?id=379_

[johanhaleby]

_From [email protected] on December 30, 2014 01:07:21_

REST Assured has not been designed for parallel testing unfortunately. The best way to make it work in parallel would be to make everything immutable. And the API's have been designed to allow this (since is why the configuration can be a bit quirky for example). But under the covers REST Assured mutates state internally which is a big problem for parallel tests. Perhaps I should have written it in Clojure instead of Groovy :)

[johanhaleby]

_From [email protected] on January 07, 2015 23:47:37_

Thanks for the feedback Johan!
That's unfortunate but looks like we'll have to live with it.
Cheers

[whiskeysierra]

Are there any plans to tackle this? Since HTTP-based tests usually take longer than normal unit tests this would be a big selling point imho. Also in terms of the API it wouldn't be that hard to change I think (no clue about the internals). My first rough idea:

final RestAssured rest = RestAssured.create(8081);

rest.
    given(). // no longer static
        // business as usual

[johanhaleby]

@whiskeysierra That looks like a nice API and it would be great if REST Assured were to support this. Unfortunately I can't see myself having time to implement this in the near future. You're very welcome to have a go at it yourself if you like (a pull request would be greatly appreciated).

[andersmartini]

Whats the status on this issue? I kind of really need this, and I'm willing to put down some time on it if needed. @whiskeysierra 's propsal seems very reasonable to me, is there a branch/fork where work has begun perhaps?

[johanhaleby]

There's a pull request that might have fixed this: https://github.com/rest-assured/rest-assured/pull/851

Would be great if you could try it out and comment.

[rvarum]

just out of curiosity, if you use forking and not threading, meaning new JVM process spawned for each class and also disabling fork reuse - which both can be achieved with Maven Failsafe (and I think also Surefire), wouldn't that solve this problem as the resources are isolated in separate JVM?

it would cost more hardware sources though than simple threading.