frankkDLL
Occasional Contributor
Joined 9 years ago
User Profile
User Widgets
Contributions
Re: Ready! API and GIT SCM struggles
Hi TanyaYatskovska - that's fair enough. I admit i was of the impression that the support team would keep an active eye on the community discussions. We've ported from v2.5.0 to v2.6.0 this week, so I will evaluate if we still have the issues with the latest version of Ready API. I read that there were some improvements made to the GIT integration1.5KViews0likes3CommentsRe: Ready! API and GIT SCM struggles
@TanyaGorbunova i still see no clear evidence as to a fix for this issue. Surely, instructing someone to ingore this issue and create a new issue is masking how long teams have been struggling with the integration between Ready API and SCMs? We are still working around the issue via a manual process.1.5KViews0likes5CommentsRe: Script import issues "java.lang.NoClassDefFoundError" following upgrade from 1.9 to 2.0.2
The short-term resolution is to download and add the following JAR to "C:\Program Files\SmartBear\Ready-API-2.0.2\lib" and then restart Ready API 2.0.2: http://central.maven.org/maven2/net/minidev/asm/1.0.2/asm-1.0.2.jar I am hoping the missing JAR is automatically bundled in future versions.10KViews0likes0CommentsScript import issues "java.lang.NoClassDefFoundError" following upgrade from 1.9 to 2.0.2
Hi All, Getting the following errors running scripts locally in virt-server following upgrade to 2.0.2 ERROR:java.lang.NoClassDefFoundError: net/minidev/asm/FieldFilter ERROR:java.lang.NoClassDefFoundError: Could not initialize class net.minidev.json.JSONValue The script being run in the virts (which runs fine in 1.8 and 1.9) has the following assembly imports: import java.util.ArrayList; import java.util.List; import net.minidev.json.JSONObject; import net.minidev.json.JSONValue; import org.apache.commons.lang.StringEscapeUtils; import com.eviware.soapui.support.types.StringToStringMap; Dodgy install or have certain assemblies/libraries been removed? Rgds, FrankSolved10KViews0likes2CommentsRe: GIT Integration - multiple projects in a single repo
Hi msiadak, Thanks for the response. I see a big difference in having multiple projects versus multiple GIT repos. Agree that a test project should be kept as succinct as possible but we really should not be limited from having multiple independent projects in a single GIT repo. From a .NET perspective, you can have multiple independent solutions in a GIT repo, developers simply pull down the solution they are interested in working on and do not need to worry about other solutions within the repo. Having multiple repo's is a real nightmare when it comes to CI/CD. I want our test projects to live in the same repo as our actual APIs and have our CI/CD DTAP specifies as branches in the repo (feature specific, TST, Staging, PRD). When CI is running it can then deploy the APIs to the relevant target then on a separate task, pull the relevant test project associate to the API and execute the tests etc. Having to jump to different repos is a real pain and it also does not keep control in the Continuous Delivery pipeline. At least IMO this is sub optimal and leads to much more overheads of trying to keep different repos in sync (e.g. the actual API delivery code and the related API test suites)3.1KViews0likes0CommentsReady! API and GIT SCM struggles
Hi All, Just wondering if some of you could offer some advice on using Ready! API with teams where multiple team members are working on shared projects. We are using GIT as our source control management tool via the GIT integration plugin but are hitting issues where team members are losing work and in general really struggling to get consistent stability with the integration between Ready! API and GIT. A summary of how the team is working: We use Ready!API (1.9) in a team of testers (varying levels of technical ability) who: • Create and update test suites • Use each other's test suites to run tests, clone test cases • Make occasional updates to the shared environment settings Git SCM is used to share the project among the team members; Ready!API offers Git integration using a Git plugin which is bundled with the tool. The team experiences many issues with the Git integration, including: • Changes to environment and other settings being overwritten o Ready!API uses one file settings.xml for the settings. o Ready!API changes this file settings.xml every time a project is opened (should have been fixed in version 2.0, not tested yet). o When multiple team members have changed any (environment) settings, this causes Git merge conflicts. • Ready!API lacks support to automatically resolve these merge conflicts and lets the users resolve these themselves using external text editors. • With the complexity of the settings.xml files, this is beyond what can be expected of Ready!API users. • Considerable loss of work due to disappearing and overwritten test suites o When multiple team members re-order or rename test suites or test cases, these changes are not correctly brought over to other team members because of merge conflicts in files named elements.order. • Ready!API lacks support to automatically resolve these merge conflicts and lets the users resolve these themselves using external text editors. o We have also found many cases of the actual test suites (i.e. the actual folders) getting lost when team members synchronize their work via Git, but haven't found the root cause to this yet. • We see commits with the missing folders successfully pushed to the Git repository, but subsequent commits by other team members don't have those folders anymore. • In general: Ready!API's Git conflict resolution handling is implemented o In case of merge conflicts, Ready!API offers three conflict resolution methods: • Mine: this causes issues, as other's work gets overwritten by our changes • Theirs: this causes issues, as our work gets overwritten by other's changes • Recursive: this requires merges using external merging tools in many cases, which is beyond what can be expected of Ready!API's (many) users due to the complex contents of files that Ready!API uses. In order to mitigate thes issues, we have tried the following: 1. Using external Git integration tools rather than the Ready!API plugins o This still has the same issues as using Ready!API's Git integration plugin, but at least does not easily allow to overwrite each other's work. o We experience the following issue, however: • Ready!API caches project files. Hence, external changes to the project files do not correctly reflect in the project. 2. Using separate composite projects, having one team member work on a project at a time o Besides this undermines the benefits of using Git integration to share projects, this approach also is not ideal as team members want to be able to see other's work but not to change it. This can not be enforced in Ready!API. Is there a way to provide a smart merge conflict resolution method in Ready!API, which removes the need for team members to either choose whether to overwrite their own or other's changes or merge using external merge tools in case of conflicts. Ready!API understands the complex file structure and should be able to merge automatically in the majority of cases. In case no automated merging is possible, the user should be presented a more convenient overview of which test suites, test cases settings, etcetera should be copied from the local to the remote repository and vice versa. The current mechanisms expect too much of the internal working of Ready!API to its users. Would be interested to hear how other teams are overcoming these challenges. Rgds, Frank5.3KViews0likes16CommentsHow do you get the Virt DataSource row count
Hi There, Hopefully this is a trivial question, but i just can see it in the API documentation.... When accessing datasources for a request via groovy like: def virtDataSource = mockRequest.getContext().getMockService().dataSources.getVirtDataSource("SomeDataSourceName") Is it possible to get the number of rows specified in the dataSource dynamically? Rgds, Frank1.4KViews0likes0Comments