单元测试Web服务方法

Question

I am currently writing an application which is kind of a proxy between the end-user and a web service.

The user requests a service, and the application calls the web service method with appropriate parameters set, and returns the result.

To make sure nothing went wrong, I have decided to create unit tests for the project (Yep! I know it's a bit late to do it after writing the code. I'll write the unit-tests first next time).

in these unit tests, I have to make real requests to the web service to be sure no permission exception, service-related exception, etc is raised. Therefore extracting an interface and mocking the service for testing is not going to help. Is it acceptable to write unit tests, that actually call the real web service?

Is it possible to have a delay between two tests if my web service just allows for example one request per minute?

Answer 1

What you are speaking about is integration test .

It's not a problem to write such tests for your web service. They are written in the same style as unit test but testing live system and or it's parts. You can even start your web service in your test context.

And it's up to you and your test context to limit situations with call delays or simulate any other situation.

Answer 2

My understanding is that unit tests are supposed to yield immediate result. What you are after is integration tests, not unit tests.

Answer 3

It is acceptable of course, although they would me more "integration tests" than unit tests, since you are testing your whole system integrated.

What you can do to delay the tests, is to simply put a Thread.sleep(1000) in the beginning of the test.

Answer 4

What about testing the code behind the web service layer? What I have done in the past is using web services as merely wrappers to a business logic library where all the real code lives. Then you can do integration tests on this library without worrying about your web service request limits.