The collection of traffic is not what is causing the tests to run slowly. What browser are you using during playback? Which playback engine are you using (WebDriver or legacy)? What kind of element locators does your test use - Xpath element locators can be slower than other types of locators in certain browsers, especially IE. Also, the test can run slowly because the application being tested takes a long time to load each page.
did you add value for -data option?
In second command where you are using -resource you should also provide name of the project.
If you want to run all projects/tests in workspace, skip -resource option.
Hi @subratdash8 ,
UTA 10.3.4 does not report mockable invocations for mocks which are created using the @Mock annotation. This is a known limitation in 10.3.4, and we are already working to update the tool to support this style of mocking.
Portability is definitely a good thing. This is true whether designing code or designing test cases (Parasoft or otherwise). I can imagine taking one of the following approaches here:
"ssh" is available for Windows as part of Cygwin. So, it is possible to run "ssh" with the exact same arguments in such a way that would work on both Linux and Windows.
If instead you need to run entirely different commands on Linux vs Windows, then you could parameterize the path and any arguments with variables. This way you could use different values for those variables to run a different command or script depending on the environment. See Running Tests in Different Environments.
You can also consider having two different External Tools, one with the Linux command configured and a second one with the Windows command configured. You can use test flow logic to conditionally execute one vs the other based on a test suite variable.
Lastly, you could use some java-based ssh tool that is not OS specific. Perhaps you could make your External Tool call an Apache Ant script that uses the sshexec task. Or maybe you use an Extension Tool and write a little script using the jsch java library.
From a quick review it seems the file data source doesn't access the contents by the name of the file. If you switch to "form input" then you can select "parameterized" for the filterCriteria element and see what the available column names are.
In the latest MacOS they further broke support for older versions of eclipse. Previously the "-noSplash" option was able to work around enough of the issue for eclipse to run however we have observed as well that setting that flag no longer works. Unfortunately this means that you will need a new version of Virtualize for it to be able to work on MacOS.
you can integrate SOAtest with UrbanCode on several ways:
I personally would suggest to take a look on Shell/Shell (with xargs) as it might be the easiest.
For additional hints see here: Remote Execution and/or here CI
@gajinder27 Hello, at the current moment DTP doesn't have the feature/functionality to accept cucumber reports directly and display the data, however is our future roadmap.
Unfortunately, it looks like the answer is no, not at this time anyway. I believe you referring to the KeyInfo Form which is configured in the XML Signer/Encryption tools under the WS-Security section.
For background, the XML Signer/Encryption tools implement WS-Security using one of three versions of WSS4J, an open source java library. The version of the WSS4J library is configured in the Emulation Options section. Offhand, it looks like WSS4J 1.6 supports this but not the older 1.5 and 1.1 WSS4J libraries. Potentially, a new "X509 ThumbprintSHA1" option would need to be added to that KeyInfo Form combo box when WSS4J 1.6 is enabled under Emulation Options.
I would recommend reaching out to your Parasoft account representative to submit a formal feature request. Parasoft could potentially implement this for some future SOAtest release on your behalf but you need to discuss this with your Parasoft account representative.
Take a look at the External tool which allows you to invoke external scripts/tools. You could write your Powershell commands in a .ps1 or batch file and invoke it using SOAtest.