CODEWITHSUNDEEP
javaweb-servicesserializationreflectionfitnesse
java_enthu
java_enthu

Reputation: 2327

Testing thirdparty API through Fitnesse

we have to test few of the APIs which are lying on the remote machine which needs to be tested using fitnesse.

We have some pre conditions.

  1. We need to use webservices for testing these APIs. And API's jar (say xyz.jar) lies on the server side. Where webservice is to be deployed.
  2. Inputs have to be given using fitnesse. And xyz.jar is not available on the fitnesse side. Because client fitnesse needs to be independent of the changes in the xyz.jar and hence it makes it generic for all future versions.
  3. User will give what method of what class is to be tested along with input data in the wiki page.

One assumption here is using the input values and API name given on wiki page: through reflection that API will be invoked from the webservice.

SAMPLE DATA FLOW

| Fitness | ----- > | Business layer | --> | Webservice Proxy | -------> | Webservice | -------> | xyz.jar |

We are facing some issues like.

  1. Some of the APIs are are like doSomething(CustomId someId, DBLoaderType type, DBFilter filter, boolean exclude) returns java.util.List But these CustomId, DBLoaderType, DBFilter, SomeNavigationSystem are not serializable objects.

  2. Some of the APIs return the values which can be of type Java primitives, wrapper or custom objects or Collection of custom objects. (boolean, Boolean, List Map , Map> How to verify the return types?

  3. One issue we are facing is : how to input the input data from fitnesse to java layer (which will make a call to webservice to testthe API) If the API is of type registerUsersForMessage (int messageId, List users, boolean forceRegister, int maxBatch, Map ) how to pass such data to java layer from fitnesse wiki page? Is there any way to push the input data 'somewhere' so that tester's wiki page will be clean?

Any help for this is welcome. Or any questions which may lead to brainstorm awe welcome too. Thanks in advance.

Upvotes: 1

Views: 760

Answers (1)

Randy Coulman
Randy Coulman

Reputation: 546

I'm not sure what kind of app you're testing here, but I strongly recommend that you keep only the business details and logic in the Fitnesse test pages, and move all of the stuff about APIs and other technical details into the fixture code. It makes the fixtures more complex, but they're in an environment where you've got a full set of powerful tools to manage that complexity.

If you're thinking at the level of verifying the return types from the API functions, that sounds like a completely different kind of test.

The fact that there is a webservice involved to make your application work should be transparent to the Fitnesse tests, unless you're testing the web service itself.

Upvotes: 1

Related Questions