Forum Discussion
tdrury
13 years agoContributor
Right, but what I'm attempting to do is run a SoapUI test case from a junit/testng integration test, so I need to be able to call SoapUI classes from within my Java test code. That's easy enough, but my requirements are particular:
1. I need to be able to run the SoapUI test runner with specific SoapUI settings - namely, preemptive authentication needs to be true.
2. I need access to the run context of the test case after it has finished so I can fetch some properties that were set within the SoapUI test case and use them in my junit/testng integration test.
The way the SoapUI code was written, those two requirements seem to be at odds with each other. You can either run a single TestCase and have access to the context, but not be able to set settings, or you can run a test case via the SoapUITestCaseRunner and set settings, but not have access to the finished TestCase context.
I was able to use this method:
which is from the online help. I can get the TestCase runtime context via this method, but I found no way to set SoapUI settings via these classes. So I wrote my own SoapUI test runner class which does the above but also instantiates the SoapUIPro.SoapUIProCore class within the constructor of my SoapUI test runner class. (I think the same would work for the non-Pro version using SoapUI.SoapUICore class.)
So, effectively, I did this:
This just seems really "hacky" and was unsure if it would cause other unintended consequences, which is why I was hoping for some feedback from SmartBear.
-tim
1. I need to be able to run the SoapUI test runner with specific SoapUI settings - namely, preemptive authentication needs to be true.
2. I need access to the run context of the test case after it has finished so I can fetch some properties that were set within the SoapUI test case and use them in my junit/testng integration test.
The way the SoapUI code was written, those two requirements seem to be at odds with each other. You can either run a single TestCase and have access to the context, but not be able to set settings, or you can run a test case via the SoapUITestCaseRunner and set settings, but not have access to the finished TestCase context.
I was able to use this method:
WsdlProject project = new WsdlProject( "src/dist/sample-soapui-project.xml" );
TestSuite testSuite = project.getTestSuiteByName( "Test Suite" );
TestCase testCase = testSuite.getTestCaseByName( "Test Conversions" );
TestRunner runner = testCase.run( new PropertiesMap(), false );
which is from the online help. I can get the TestCase runtime context via this method, but I found no way to set SoapUI settings via these classes. So I wrote my own SoapUI test runner class which does the above but also instantiates the SoapUIPro.SoapUIProCore class within the constructor of my SoapUI test runner class. (I think the same would work for the non-Pro version using SoapUI.SoapUICore class.)
So, effectively, I did this:
SoapUIPro.SoapUIProCore soapuiCore = new SoapUIPro.SoapUIProCore(true, "/path/to/soapui-settings.xml");
WsdlProject project = new WsdlProject( "src/dist/sample-soapui-project.xml" );
TestSuite testSuite = project.getTestSuiteByName( "Test Suite" );
TestCase testCase = testSuite.getTestCaseByName( "Test Conversions" );
TestRunner runner = testCase.run( new PropertiesMap(), false );
This just seems really "hacky" and was unsure if it would cause other unintended consequences, which is why I was hoping for some feedback from SmartBear.
-tim
- This reply was moved to another post
- VernonCrabtree9 years agoOccasional Contributor
Tim,
I too am trying to call SoapUI from Java, wanting to run certain test cases with certain properties and then be able to determine what failed where (get a report).
I see that you have followed a similar path to me (based on the examples from https://support.smartbear.com/readyapi/docs/testing/integrations/junit.html) - I have a couple of questions:
1) Did you ever get a satisfactory answer from Smartbear?
2) Where do I import SoapUIPro.SoapUIProCore from? Or has this disappeared from recent versions?
- groovyguy9 years agoCommunity Hero
You are replying to a post that is almost 4 years old. You may want to start a new post for your problem.
- VernonCrabtree9 years agoOccasional Contributor
OK - will do.
I didn't realise there was an expiry date on the bottom of the package ;-)
Thank you for the response.