Forum Discussion
If you can complete and send me one of them not full collection I would be able to understand I dont think I can complete that script with that logic myself
When I sent you that soapui project - I said - all I had done is import the 1 collection (that corresponds to the postman collection that contains all the requests). I never said it included the script - cos I haven't finished working on it and I said that it did not contain the detail from the ennvironments collection .json file. I told you this so you would be aware that it hadn't been finished and there was still a lot of work todo - but at least you had the basic project in soapui to work with.
I don't know your project - I am working in the dark here. You pushed up to github some stuff which contained 2 postman 'collections'.
In fact one of them isn't a collection -its environment config.
If you look in your postman collection - you will see each request contains the setup script. The setup script is NOT imported when you import the postman collection into ReadyAPI!/SoapUI. This is one of the problems I mentioned repeatedly before about importing collections into soapui. It doesn't necessarily import everything, because the setup and structure of things in a postman collection don't necessarily match something in soapui/readyapi!.
Great example of this is the setup script. SoapUI also has setup scripts - but the setup scripts in soapui aren't at request level - they're at project, testsuite and testcase level. So we'd need to alter the setup script anyway I'm guessing in some small ways.
Right - now I'll answer the questions you asked me:
q1. "If you did not import the other json how will this work , both need to be imported and then one XML for soap ui exported out"
Answer: as I said before - I dont' know your project - I'm working in the dark here. I mentioned before that importing postman collections doesn't necessarily import everything you want because the setup/hierarchy of postman differs from soapui. I couldn't import the environment 'collection' because soapui doesn't recognise it as a collection as the content of the .json doesn't match the .json content of a collection. I appreciate you want both imported - but this is just another hurdle that youll need to overcome and find a workaround.
If you look at the content of the environment colllection .json - it appears to hold key/value pairs that correspond to 2 of the 4 project level properties. The 'RFC1123time' property is populated by the setup script I was working on - in fact thats one of the bits Ive fixed so the script will populate that property.
q2. First I dont have ready api , so it took me a while to import it manually with all parameters
When you import you should select both files and import then it will work I think
I will repeat what I've said 3 times now - I cannot import the second 'collection' json - cos its not a collection - its a .json file with key/value pairs that sets environmental stuff in postman and these equate to populating 2 of the 4 project level properties in soapui. you cant import the 2nd collection file in soapui.
q3. Also i dont see your setup script in the soapui project did you put it there ?
No - I didn't put it in there cos it isn't finished yet - I've done less than a quarter of it. Also you have the issue that the granularity for scripts is different in soapui to postman. The postman 'setup script' is at request level. soapui doesn't have setup scripts at request level. you have project, testsuite and testase level setup scripts. we need to think about how we're gonna set these up and in fact the content of the scripts might have to change to support running them at a level different to request level. Request level means the script is executed every single request. If the code content within the setup script requires them to fire each time a request is executed, then we're gonna have to find a way around this - i.e. perhaps add in a groovy script at the beginning of the test, immediately before each request is executed...??? Thats a complete guess on my part - but its possible that even if we successfully convert all the JS to groovy, the script still won't work cos it executes at the wrong level.
q4. Where are the env variables i dont see them you have create those at TC, or project level?
They were automatically created when I imported the collection. They are at project level. However - as I said in the answer to question 1, the environment variables (project level properties) are populated from several different things. 2 of the properties would be populated with the environments collection .json file. 2 of them (RFC1123Time and authtoken) are populated with the setup script. Hence the reason why the 4 project level properties are blank in the project I attached.
Cool?
rich
- ameesh19844 years agoContributorWhat you would suggest is the best way to handle this since the collection cannot be imported directly into soap ui
- ameesh19844 years agoContributorCan you import the collection as JS and see if it works in soap ui , not groovy
Does it import the full thing ? - richie4 years agoCommunity HeroHey ameesh1984,
I dont know what you mean by the following:
"Can you import the collection as JS and see if it works in soap ui , not groovy"
I am importing the collection, but you dont get the choice to "import as js" or "import as groovy".
The script language is one of the default (not custom) project properties. Once you have a project created in soapui, you can then switch the script language from groovy to js. Thats it. - ameesh19844 years agoContributorWhat I meant is can u import collection as JS language project and just run it as the pre script is in js
- ameesh19844 years agoContributorNever mind
Were you able to get a call working to your cosmos from rest api ?
Related Content
- 2 years agonormgean
- 10 months agoRicky1
- 4 years agoTommyTester
- 10 months agoMussieG
Recent Discussions
- 6 days agoruchisingh