Ramiro Martinez admin
- Ramiro Martinez
- Last Active
- Admin, Staff
Would you please try going through the steps provided in the attached PDF:
If you cannot access the PDF file, I have added the steps below:
SOAtest and/or Virtualize 9.9.3 is unresponsive on MAC OSX 10.11
Parasoft Internal Notes
Details On Eclipse 4.5 and Mac OS X 10.11, there is a known issue with the workspace launcher freezing (becoming unresponsive)
when Virtualize or SOAtest opens up. The workspace launcher is shown but is unresponsive even after clicking on
the buttons to select a workspace. You are forced to close SOAtest or Virtualize.
Launch Virtualize or SOAtest from the MAC terminal with -noSplash parameter and without modification to
eclipse.ini. You will need to navigate to the install location and change directories into the Contents folder to be
able to find the start up script. For example, the install location could be:
and then you just execute the following:
If you are not able to see the SOAtest or Virtualize launcher script, right click on the application and chose "Show
Package Contents". From there, click on "Contents -> Parasoft(SOAtest/Virtualize)" and the launcher script will
be located in the directory.
Please make sure that the XPath for "has content" assertions point to an element and not to the value of the element.
Would return 123
Would return the entire element "a"
Has Content assertion expects an element not a value.1
I am a bit unclear about what exactly is your end scenario.
Are the following requirements correct?
1. Request and response pairs in the same.
2. Each pair of request and response should be in a different file.
If the above is correct then you will want to use the File(write file) tool chained onto the client's "traffic stream".
This will now add the request and responses into a single file, now to separate these pairings into separate files you will want to configure the name of the file that is created by the Write file tool to be unique for each pairing.
This can by adding %t to the name of the file, these characters add the time to the name. For more options Click "Help" next to the file name text box.
Example of output of names:
If this is not your use case and you are actually trying to separate the request and response pairs as well , then you will have to use the naming concept from this post and the "write file" tool configurations from Omar's post above.
I suggest looking through the SOATest documentation for "write file" tool, especially the Customizing write file section as it goes into dept explaining the naming options.
You cannot chain anything to the Traffic viewer as the traffic viewer is not outputting any data to another tool. The messaging client is outputting data, therefore it is possible to modify it with the different tools.1
If your two responders are in the same PVA then you can use Test suite variables which are cached during run time and will persistent from one response to the next.
The scenario would be the first request comes in and hits the first responder due to specific request correlation.
Chain a data bank tool to the first responder and extract whatever information you need for your second request and save these values into the test variables.
When the second request hits the PVA, then the correlation from your first responder should make this request incompatible with the first responder therefore it will hit the second responder.
This responder will parameterize the values from the test suite values, which should have the values that were previously saved from the last request.
The test suite variables will reset after re-deployments and restarting the Virtualize server.
Please note this scenario, will only keep one set of data from previous calls.
If this does not fit your scenario, then you may wanna try using the "write file" tool to keep a hard copy of the data and then call on that file with a messaging client(transport-less)/data bank tool.
Have you tried the XML/JSON assertor with a numeric assertion?
The numeric assertion has the options '<', '>', and other comparison options.
For your use case, I suggest data banking the values you need to compare and then calling them in the XML assertor.
Due to visibility restraints you will need to call the variables manually using:
I suggest changing the variable to make it easier to call the values.
Short example below: