mrugglesaz
Occasional Contributor
Joined 12 years ago
User Profile
User Widgets
Contributions
Re: Make File Lookups Relative for Composite Projects
Rao: I don't understand how this feature request process works. You gave me a link to raise a feature request that takes me back to the same page where I started this thread. I thought that's what I was doing with this request. If you could please submit this request "as is" I'm sure someone who is more familiar with the relative lookup functionality will probably understand the scenario I'm proposing. I would also be happy to take a phone call with one of the engineers to demonstrate what I'm talking about. Thanks, Mark Ruggles1.2KViews0likes0CommentsRe: Make File Lookups Relative for Composite Projects
This works, but only because you are supplying so much of the directory path in the File path field. That kind of defeats the purpose of the original functionality of designating the Resource Root property. When you use ${projectDir} as the Resource Root, at least for regular projects, all you need to enter in the File path field is the name of the file you are looking for, no extra path information is needed. That is most helpful when sharing a project with someone else since ReadyAPI will look in the directory where the project file is stored. All another person needs to do to get tests running correctly on their machine is to have the data source file in the same directory as the project file; ReadyAPI takes care of finding the file in the background. However, it is not so with composite projects, which is a shame because composites are meant to be shared with other people to work on them collectively. Yet, relative lookups don't work correctly. It would be great if this could be fixed. In the meantime, we have found a workaround that is finally working for us. The local and remote folders have to be named exactly the same. Git renamed the remote to have dashes where there were spaces in the local directory name. In other words, CSBook SWS Build PNR Project (local) was renamed by Git to be CSBook-SWS-Build-PNR-Project (remote). Once I renamed my local to match Git, then we were able to enter something resembling a relative lookup using the following File path value: CSBook-SWS-Build-PNR-Project/Datasource.xlsx It's not exactly the same as the Resource Root functionality, but it's working. If the Resource Root functionality could be fixed for composite projects as a low priority, that would be a better solution. Thanks.1.2KViews0likes2CommentsRe: Make File Lookups Relative for Composite Projects
The use case is any ReadyAPI composite project that is checked into a repository so that multiple team members can work on it together. Primarily the resource files in question are those used by Data Source steps like spreadsheets, XML files, etc. Entering the File path to a spreadsheet that feeds a Data Source step cannot be made relative to the project directory after making the project a composite since the directory structure is dramatically changed after doing so. In a regular project, setting the Resource Root setting to ${projectDir} makes the file lookup relative to the directory where the project XML file is stored. If you store a spreadsheet in the same directory as the project XML file, then simply entering the name of the file in the File path field in the Data Source step will locate it. However, in a composite project, the XML file is divided into smaller units so that there is no longer one main location so a lookup relative to the project file's location isn't possible. Since a composite project seems to be based upon building a folder structure that mirrors the project structure inside of ReadyAPI, can an option be added to make lookups be relative to the parent directory of the project? This would be equivalent to the project level in ReadyAPI. The attached screenshot shows this concept.1.3KViews0likes4CommentsMake File Lookups Relative for Composite Projects
For regular projects in SoapUI Pro, you can set the Resource Root at the project level to be either ${projectDir} or ${workspaceDir} so that file lookups will be relative to the directory where the project or workspace file is stored. Given how this works in a regular project, I assume that files are being located relative to where the project XML file is stored, meaning that my files will be found if they are in the same directory as my [project name].xml file. However, for composite projects, this isn't possible since the project is broken up into several small XML files representing the separate test cases within the project. Would it be possible to add an option in Resource Root for the parent directory of a composite project so that all file lookups are relative to the parent?1.3KViews0likes6CommentsReplace the Option to Disable Tooltips
We don't all use tooltips in SoapUI. Please replace the option to disable tooltips in Ready! API. I find that the tooltips always get in my way and I get tired of seeing them. I shouldn't be forced to use them if I don't want them. Thanks.1.4KViews0likes0CommentsAllow More Than One Message Exchange Window to be Opened at a Time
When executing a test case within the SoapUI NG GUI, you should return message response viewing to the way it was before NG - you should be able to view the responses for more than one step/iteration at a time and the window should be opened as a separate tab to the right of the test case tab. Opening a message exchange window in a separate window and only allowing one to open at a time does not allow me to view results of iterations side-by-side. This was a valuable function for debugging data-driven tests that had failures on selected iterations. Please return the message exchange windows to their former functionality.1.3KViews0likes0CommentsRe: Output JDBC Query & Results to Text File Using TestRunner
Forum Members: In case anyone is interested, the attached text file contains a Groovy script that gets the SQL Query & Results for any JDBC steps that are found in a test case and then appends them to the text file(s) that are output by executing the TestRunner. The script has worked for me in most cases. The only failure I've seen is in a test where I've set up a Conditional Wait using a Conditional Goto step along with a Delay step. Because of this design, the output of my final SQL query gets written to the wrong file, but that's only a minor bug with the script. Otherwise, this script will output your SQL Query & Results for tests with single or multiple iterations to the appropriate text files. FYI, in order to get the appropriate output directory to parse, I had to use an input box, which is displayed when the TestRunner executes. In order to see the input box displayed, you have to check the Enable UI feature on the Basic tab in the TestRunner popup window. The input box was the only way that I could find to get the same path as what is entered in the Root Folder field on the Reports tab in the TestRunner. I checked the API's and I can't find anything that let's me get the Root Folder value programmatically. This is the best design I could come up with. If anyone can improve upon it, feel free and let me know what you come up with. Thanks, Mark A. Ruggles2.8KViews0likes0CommentsRe: SoapUI Environments Functionality Only "Half-Baked"
SagarArcher wrote: Hi, Any update on this? I have been facing the JDBC issues [the JDBC connection doesnt change to the new environment after switching it from the previous environment]. I am using the latest SOAP UI version [4.6.0]. Please let me know if there is any workaround for the same. Regards, Sagar Sagar: I figured out a workaround of my own. Here's the procedure that I use. One caveat, you must use the Environments functionality to make this work. 1. I created all of my JDBC connection strings per environment as Global Properties. The Password must be included in the string. 2. I have a Groovy script that uses case statements that assign the appropriate JDBC connection string to a Project Proeprty for the Environment selected in the drop-down. 3. I added a data pull in the Connection String field in the JDBC step that gets the string from the Project Property. The Password field is left blank in the JDBC step. 4. I added a line in the TearDown Script to set the Project Property to blank again after the test is executed to remove the Password from it. The design above keeps sensitive database passwords out of the project and keeps them in Global Properties, which are specific to a user's local copy of SoapUI. This is the best design I could think of to get around the disconnect between Environments and JDBC steps. The above design does work and I have updated all of my tests to use it. Now when I select a new Environment value from the drop-down, my Groovy script takes cares of assigning the appropriate JDBC connection string for that environment. Give it a try and let me know if you have any questions. Mark A. Ruggles1.8KViews0likes0CommentsSoapUI Environments Functionality Only "Half-Baked"
Smart Bears: I recently started using the Environments functionality in soapUI Pro 4.5.1 and although this feature greatly improves the efficiency/reusability of certain test cases in my project, there is a list of things that I've found that makes me think that this feature needs to cook a little longer to make it flawless. Below is a list of improvements in order of importance. Issues with soapUI Environment Functionality: 1. Adding new WSDL's to a project does not update existing environments. • Adding/deleting a WSDL does not refresh tree view. You have to close & reopen soapUI to see the changes. • Effectively, you have to delete all the environments so that cloning test cases starts working again correctly. 2. Changing environments does not change the associated JDBC connection string in various JDBC test steps. 3. Selecting an available Environment in the drop-down on the Overrides tab in the TestRunner dialog does nothing. 4. Related to the above, you have to click the Save All Projects button after selecting an environment from any other drop-down to apply the change to the TestRunner. Without clicking the Save All button, the TestRunner remembers the last environment that was used and does not apply the endpoints for the newly-selected environment. 5. After adding a blank environment, if you open a blank JDBC connection associated to the environment, but decide to cancel out of the dialog before entering any information, the JDBC connection is deleted from the environment. [BUG] 6. Related to the above, there should be some interface in the individual environments for adding/removing JDBC connections that are available at the project level. There should be some mechanism to mark a JDBC connection as the default for any given environment. This would create a hierarchy where the project contains all the available environments and the separate environments are able to be configured from the overall list stored at the project level. This is a must for any projects that contain a combination of tests that are used in both TEST/PROD. 7. No ability to sort the order or move the environments in the list. 8. When adding new environments at the project level, the F2 and ENTER keys should provide the ability to edit cells and open environments, respectively. Adding new environments should be an activity that can be performed without a mouse. 9. Overall, the ability to add, edit, and delete environments needs to be improved. Since I am constantly editing my soap project and adding new WSDL's to it (it is a template project that's used to run validation tests during production implementations), the shortcoming listed in Item #1 has caused me to start storing my endpoints in Groovy scripts, which are used to update my test steps based on the Environment value selected. After adding and deleting a list of 30 environments with 16 endpoints each a couple of times, I quickly grew tired of that activity and moved my endpoint dynamics to Groovy, which, believe me, I understand defeats the purpose of adding Environments to a project in the first place. Environments are great if you never plan to update your project again. However, in the real world, projects are reused and updated all the time. There are many things in soapUI that are configurable and dynamic; adding new WSDL's to Environments should be one of them. Thanks, Mark A. Ruggles6.1KViews0likes3CommentsOutput JDBC Query & Results to Text File Using TestRunner
Smart Bears: It would be great if the JDBC test step would output the query used and the results returned in the text output file that's created when executing test via the TestRunner. Currently, the JDBC test step only outputs a header with a timestamp (see attached output file); the query used and the results returned are not displayed in the output file anywhere. I work for a company where saving testing artifacts is a must for auditing purposes. If the SQL query and results were output directly from my JDBC test step, it would save me extra screenshots and SQL query output files using SQL Server Mgmt Studio. I would rather do all my database manipulations/queries in SoapUI and be able to prove what I did in the TestRunner output files. Please consider parsing out the query that's used in the JDBC step and putting it in the request section of the output file and putting the query results in the response section (even in XML format if necessary). This would be a great time saver for me and my team. Thanks, Mark A. Ruggles5.6KViews0likes1Comment