tgeliot
Contributor
Joined 10 years ago
User Profile
User Widgets
Contributions
What are "Plain" parameters useful for?
SOAPUI Pro / Ready API offer several kinds of parameters for RESTful resources and requests. One of the types is "Plain". The documentation says "PLAIN parameters are defined in the request and can be accessed, but are omitted when sending the request." What on earth are these useful for?2KViews0likes2CommentsOn Ready!API GUI, make it very obvious if something is currently executing, and if so, what
We have machines in a shared lab that individuals will sometimes initiate runs of test projects, suites, or cases. Sometimes these will run for hours. When another user walks up to the machine, there is no easy way to tell if that is going on. If someone knows what project, suite, or case is executing, they can select it and look at its Transaction Log, and get an idea of where it's executing. But if someone navigates away from there, it becomes very difficult to tell. When something is executing, I want a big red indicator that flashes, saying EXECUTING TEST or something like that, and when clicked on, it will do something useful like telling me which test, or navigating to that item. We had a discussion on this here.1.2KViews0likes0CommentsCan't select and import composite project in ready!api 1.9.0
In Ready!API 1.9.0, if I try to import a composite project, I can't. I select "import project" from the file menu, and it pops up a file selection dialog that is different from the one that was in 1.8.0. I navigate to the directory that contains the project, select it, and click "open". But instead of opening the project, the dialog just drills down into the subdirectory. To work around this, I shut down 1.9.0 and bring up 1.8.0. In there, I import the project. Then I switch back to 1.9.0, and when it comes up, it has the project in its workspace.Solved2.5KViews0likes2CommentsRe: TestRunner believes test step has failed when it succeeded
What I can say now is that some combination of recreating the Groovy script test step, eliminating the earlier Groovy script test step that really was failing, and going to Ready!API 1.9.0 has at least made the problem go into remission if not fixed it completely. I'd say that we can declare this "fixed" and I'll re-address the issue if it comes back.2.2KViews1like0CommentsRe: TestRunner believes test step has failed when it succeeded
Yesterday I made two changes: 1) I created a new Groovy Script Test Step, and copied and pasted the text from the old test step into the new one, and disabled the old test step. This was just in case somehow the metadata for that original test step had gotten corrupted. 2) I disabled a different Groovy script test step that occurred earlier in the test case, that was always failing. The next run of the test suite ran OK. I've installed 1.9 and am running the test now.2.3KViews1like1CommentTestRunner believes test step has failed when it succeeded
I have a Ready!API project that I've been using for a while. It gets run at night using TestRunner. Both my local instance of Ready!API and the one used at night are version 1.8.0. One of the test steps is a Groovy script. It has worked OK in the past. The log shows the messages that go with a successful termination of the script. But now, no matter what I try, Test Runner believes that the test step has failed. I'll attach my script. But wait, there's more! Despite the test case having the "Abort on Error" and "Fail TestCase on Error" flags NOT checked, TestRunner declares the Test Case to have failed, and doesn't run any of the remaining test steps. I'll attach an excerpt of the Jenkins log. I've had to edit it a bit to remove some sensitive information, replacing test case names with xxx and the like. One possible issue is that there are test steps that run earlier in the test case that DO genuinely fail, and get retried until they either succeed or we give up. But we want to try all those steps, even if some fail; this is why these checkboxes are unchecked. Perhaps the failure of an earlier test step is somehow contaminating TestRunner's understanding of what's happening with this test step?2.3KViews0likes3Commentshas been modified externally, overwrite?
I have about a dozen composite Ready!API projects open in Ready!API. This isn't the first time I've done this. This is just working on my local machine. Nobody else has access to this disk. I checked the files out from Subversion, and then Imported them into Ready!API. As Ready!API sits there idle, it will suddenly pop up a box that contains a message dialog like: Save ? File for [bc33b1d9-8008-4951-bff9-00aa88cce412] has been modified externally, overwrite? Yes No I hadn't touched anything on the Ready!API screen for a while before it did this. I click Yes (I'm not sure why I chose Yes instead of No :-), and that box disappears, only to be replaced by another, and another, and another. I click as fast as I can for a long time, closing countless such boxes. Five minutes later, it all happens again. So far it's just a big annoyance, but I don't know if my project files are getting corrupted or anything. Any clues here?3.1KViews0likes2CommentsTransferring information from Ready!API to Jenkins log when there is not any error
I'm not sure if I should be asking this here or in a Jenkins forum. If you think there's a better place for this question, please direct me. We use Jenkins to invoke Ready!API test packages (Jenkins calls TestRunner). If there is an assertion failure in the Ready!API test, the name of the Assertion, and sometimes some other information associated with it, end up in the Jenkins log (aka Console Output). I would like to be able to selectively send small amounts of text (e.g. file pathnames) from the Ready!API test step up the food chain so that they appear in that Jenkins log, even though there is no error or assertion failure. Think of it as doing a log.info call. I don't know if I should be looking at some Ready!API facility, or configuration in Jenkins, or what. Google hasn't been my friend here.749Views0likes0Comments