Waiting between test cases

[asmodehn]

Since Rester assumes order between tests cases can make a difference ( and that also the reason I decided to use it ), It would make sense to me to allow waiting between test cases... However we probably want to avoid going too far into the "programmatic test" domain.

Is there a way to wait between test cases of the same suite ? If not, is this something doable/suitable ?

[chitamoor]

Rester currently doesn't support waiting between test cases. All the HTTP requests are synchronous/blocking, so in some sense, Rester waits for a response before it moves to the next request, but are there particularly use cases that you can think of for the "wait" feature?

[asmodehn]

Well it s quite a specific use case... I m working on robotic applications. For ease of use, especially to interface with internet, website and web services we use a REST API to give commands or get data from the robot.

Which is why it cannot be completely stateless. Where the robot is in the real world will always matter and can lead to different outcomes.

So in my case the order of request matters and also the time when they are done ( the robot can be doing something at some time )

I had a quick look at the test format, and we could see it as a "scenario" describing a particular "use case". So the waiting could be done by implementing delays before or after a step. The code just reads the scenario and do the action at the specified date/after waiting a specified delay.

It could be also thought as a"condition to wait for" until executing the step. I m think this could also be used as "wait for that GET request to return this data, before executing next step"...

[asmodehn]

Exemple :

• POST http://robot:8080/ros/travel payload : {'destination': 'kitchen'} <- OK 200
• Wait until GET http://robot:8080/ros/location <- OK 200 { 'location': 'kitchen' }
• POST http://robot:8080/ros/grab payload : {'object': 'apple'} <- OK 200 etc.

The trick is that when sending the robot to the kitchen, because the robot is moving, we can loose network connection, we dont know how long it will take, etc. So the service has to return right away that he understood the order ( I dont see a better way at the moment... ). Then in the background, the "state" of the robot ( ie position in the real world ) is changing... So before sending the next request, we need to make sure our "expectations/prerequisites" for this step are met.

PS If you have a better idea for this kind of use-case, that will be more "RESTful", feel free to advise, I am all ears :-)