ContributionsMost RecentMost LikesSolutionsRe: [Resolved] Customized JUnitReportYes, since they get parsed by jenkins in a seamless way to our CI environment.[Resolved] Customized JUnitReportHi, We are currently trying to add more information of failed test cases into the JUnit report that soapUI creates. The report itself gets aggregated to our CI-environment and it would be nice to present more information in the test cases in the same place. However we are triggering the execution via SoapUIProTestcaseRunner like this (pseudo): SoapUIProTestCaseRunner runner = new SoapUIProTestCaseRunner(); runner.setProjectFile("myPath"); runner.setJUnitReport(true); runner.setPrintReport(true); runner.setOutputFolder("myOtherPath); runner.run(); And the code is run from a JUnit-wrapped Java class. Now the question is how to insert more information to the failing test cases into the JUnitReport. I've looked into this thread: https://www.eviware.com/forum/viewtopic ... dea#p40107 And this blog: http://blog.infostretch.com/customizing-soapui-reports But with no luck. The nicest solution would be to extend the JUnitReportCollector (or the JUnitSecurityReportCollector??) and add the messages that we want to the failing test case. However I cant really figure out howto instantiate the customized ReportCollector to the runner. Since the SoapUIProTestcaseRunner is extending the SoapUITestcaseRunner there is not possible to override method from the SoapUITestcaseRunner. So I'm a bit stuck with this. Question is: How to customize the JUnit report programmatically when using SoapUIProTestcaseRunner? RegardsRe: Version mismatch from external jarsThanks for the response! Well yes I have tried that and it solves slf4j issue, but then I fail on the next dependent jar. That could go on for a lot of common libraries, I don't really know how many right now. And I'm not to confident that it is the best solution to change versions of the jars that soapUI needs. That could result in a unstable soapUI client. And in the end it will result that all testers with a soapUI client also would need to replace the jars which complicates it even more. So I guess that the bin/ext and lib loading is tightly coupled to the same classpath?Version mismatch from external jarsHi, I currently have a problem regarding loading external jars into soapUI pro. We have a jar that is build inhouse but depending on other jars (nested), in this case slf4j (version 1.6.1). As the lib directory contains slf4j version of 1.5.8 there will be issues when trying to access classes within the external loaded jar. Is there a way to resolve this issue or are all external jars loaded into same classpath?New sessions for each request when load testing with SOAPI am using Soap UI Pro but the licence is registered to the company so I have to post in this forum since I can't find the correct login. I am running load tests from 4 instances of Soap UI where 3 of them are running from the same client. The purpose is to stress the database (Oracle) and get a reference point in test that behaves roughly the same way as in production. Even though I can generate enough load to simulate our production environment during peak time, the database in our test enviroment doesn't behave as expected. It has almost no waits and no concurrency under heavy load. The application layer looks fine so no bottleneck there. The theory is that it has to do with sessions being reused when I run the load tests from soap. In production enviroment conflicting sessions can lead to wait times in the database. Is there any way to get soap to create new sessions for each request? (The checkbox "Maintain HTTP session" is unchecked in TestCase option, but this doesn't seem to have any affect.)Groovy Script authentication - only need to run onceHello, I have a test case in Soap UI that contains a groovy script for generating an authentication ticket followed by a number of actual service requests. The authentication ticket is valid for about 20 minutes. Will the ticket get re-generated each time I run the test case in LoadUI? If so, how can I make it so that it only runs once at the start of the run? (I think the groovy script has to be in the same test case as the requests since they are dependant on eachother.)