Using Java API calls from SOAtest

LegacyForumLegacyForum Posts: 1,669 ✭✭
edited December 2016 in SOAtest
Hi, I am working on a project where we need to do some load testing against a third party Java SDK API.
I know the method calls, which are just search executes and have some of the Java code to call these methods.

However, I am not familar with how to use SOAtest to do some load testing against this third party product.
Here are some questions I have:
- Do I need to load in the librarys from the Java SDK API?
- What type of file do I need to create in the src folder in the project?
- Do I need to write out the contents of the output object in order to know when the response comes back? (I am trying to measure response timings) or will SOAtest be smart enough to know when a response gets sent back?

As you can tell I am not a java developer, but have been using SOAtest for mainly Web Service testing.

Any insight will be greatly appreciated.
Tagged:

Comments

  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    Hi Mikey,

    There are several approaches that you may be able to take, depending on your preference and the nature of the tests you want to perform. Ultimately, there will need to be code written to "wrap" the 3rd party SDK so that SOAtest / LoadTest can use the SDK. If you are not comfortable writing this code yourself, perhaps you can coordinate with a developer to accomplish your testing needs.

    Load Test needs functional tests to run, so the first thing you'll need to do is create these functional tests. This can be either in the form of a SOAtest .tst file, or a JUnit test. Load Test 9 can build a load test based on either, and will automatically track run times for you (and save statistics). To answer your first question - yes, you will need to import the SDK in the form of .jars or .class files.

    Option 1 - JUnits
    If using a JUnit, you can create a Java Project containing the JUnits and add the SDK to the classpath for the project. Then, when creating a Load Test from it, add the SDK .jars to Load Test under File > Customize Preferences > System Properties. For more information about using JUnits with Load Test, see the documentation under Help > Documentation > Load Test Procedure > Creating Load Tests Driven by JUnit Tests. This is a good option if JUnits are already written - but is limited in the availability of staistics available to LoadTest.

    Option 2 - Extension Tools
    You can also use SOAtest to create a .tst file that contains Extension Tools. An Extension Tool can use a Jython, Javascript, or Java method to call SDK functions, then return pass/fail (or results, which can be passed to other validation tools, like an XML Assertor or Diff Tool). To run the test successfully, the SDK libraries need to be added to the SOAtest System Properties under Parasoft > Preferences > SOAtest > System Properties. For more information about using Extension Tools, take a look at our documentation under SOAtest User's Guide > Reference > Extensibility (Scripting) Basics.

    Option 3 - Custom Transport
    Finally, if the SDK implements some kind of messaging protocol (such as a custom transport), you can use the Custom Transport functionality in SOAtest. This allows you to use the Messaging Client or SOAP Client to build the request message. To implement this, you will need to create classes to implement ICustomTransport, ICustomConnection, etc. Then, import your code into System Properties in SOAtest (and again in LoadTest) and switch a SOAP or Messaging Client to Custom Transport. You can find documentation on these interfaces in the SOAtest Extensibility API docs.
    Custom Transports are best when the Messaging / SOAP Client functionality is useful and the SDK implements a transport. It makes for a nearly seamless transport integration with SOAtest, making tests and code more reusable. But it can also be the most difficult to develop. If the Messages are not XML / SOAP, or if the SDK is not for messaging, then you may want to use straight Extension Tools instead (option 2).
Sign In or Register to comment.