Soapui Pro losing my test step changes?

[Said]

Hi there,

Repeatedly I am loosing changes made in my test-step. These are usualy xpath match or groovy script assertions within the test step. After re-opening the project (next day) I notice that some of my changes are gone.

What is causing this? How can I resolve this issue?

Thanks in advance!

[Radford]

I've noticed this happening occasionally (Note: I'm running version 1.7), though I've never been able reproduce on demand, or been certain enough to be sure I didn't do something wrong.

My solution was to add the below script as the  "TestRunListener.beforeRun" event, this checks all of my test step assertions for common mistakes or issues I've seen, on finding a problem it just logs a warning message. At the very least I'm alerted to an issue immediately while things are fresh in my mind, this and source control help me a lot.

This script could easily be expanded as required.

import com.eviware.soapui.impl.wsdl.teststeps.assertions.basic.*
import com.eviware.soapui.impl.wsdl.teststeps.assertions.http.*
import com.eviware.soapui.impl.wsdl.teststeps.assertions.jdbc.*
import com.eviware.soapui.impl.wsdl.teststeps.assertions.jms.*
import com.eviware.soapui.impl.wsdl.teststeps.assertions.soap.*
import com.eviware.soapui.impl.wsdl.teststeps.assertions.GroupAssertion
import com.eviware.soapui.impl.wsdl.teststeps.assertions.MessageContentAssertion
import com.eviware.soapui.impl.wsdl.teststeps.assertions.ProXPathContainsAssertion
import com.eviware.soapui.impl.wsdl.teststeps.assertions.ProGroovyScriptAssertion
import com.eviware.soapui.impl.wsdl.teststeps.ProJdbcRequestTestStep

def logPrefix = 'TestRunListener.beforeRun:' + testRunner.getTestCase().getName() + ": "

testRunner.getTestCase().getTestSteps().each{testStepName, testStep  ->

    logPrefix = 'TestRunListener.beforeRun:' + testRunner.getTestCase().getName() + ':' + testStepName + ": "

    // Only check enabled test steps.
    if(!testStep.isDisabled()){

        // Test step specific checks.
        if(testStep in ProJdbcRequestTestStep){
            if(testStep.getAssertionList().find{ jdbcAssertion -> jdbcAssertion in JdbcStatusAssertion } == null){
                log.warn(logPrefix + 'This is a JDBC Test Step, but does not have a JDBC Status assertion.')
            }
        }

        if (testStep in com.eviware.soapui.model.testsuite.Assertable){
            testStep.getAssertionList().each{ testAssertion ->

                // Generic assertion checks
                if(testAssertion.isDisabled()){
                    log.warn(logPrefix + 'Assertion "' + testAssertion.getName() + '" is disabled.')
                }

                // Specific assertion type checks
                switch (testAssertion) {

                    case ProXPathContainsAssertion:
                    case XPathContainsAssertion:

                        if(!testAssertion.getPath().trim()){
                            log.warn(logPrefix + 'Assertion "' + testAssertion.getName() + '" XPath Expression is blank.')
                        }

                        if(!testAssertion.getExpectedContent().trim()){
                            log.warn(logPrefix + 'Assertion "' + testAssertion.getName() + '" Expected Result is blank.')
                        }

                        if(testAssertion.getName().equals('XPath Match')){
                            log.warn(logPrefix + 'Assertion "' + testAssertion.getName() + '" still has the default name.')
                        }

                        break

                    case ProGroovyScriptAssertion:
                    case GroovyScriptAssertion:

                        if(!testAssertion.getScriptText().trim()){
                            log.warn(logPrefix + 'Assertion "' + testAssertion.getName() + '" Script is blank.')
                        }

                        if(testAssertion.getName().equals('Script Assertion')){
                            log.warn(logPrefix + 'Assertion "' + testAssertion.getName() + '" still has the default name.')
                        }

                        break
                }
            }
        }
    }
}

[richie]

Hey @Said

I'm using ReadyAPI! v2.4.0 and I notice this occasionally.  I'll make an assertion change or alter a parameter value and the change doesn't stick.

I would make a change - click somewhere else - run a test and it would fail and then I'd notice the change hadn't 'set' - so even hitting save and closing ReadyAPI! wouldn't save the changes because the changes hadnt 'set' when I made them.

I got into the habit of making a change - clicking out of the field (to move the focus) then click back to see if the change had been set - sometimes it had, other times it hadnt.  If it had - I'd hit save (and the changes would be saved successfully), if it hadnt - I'd make the change again and then hit save.  I noticed it more with REST parms than anything else - but it did occur in other functions as well (assertions etc.)

I've got no advice to help with this other than to say that to recheck certain changes after theyve been made to make sure the changes actually stick.

rich

[HimanshuTayal]

@Said,

Yes I have also face this issue too several times but never re-generate the issue.

I saved some groovy code into the TearDown of TestCase and whole day i worked on it and at EOD i saved my work and left for the home, but next day when i came back that code only that groovy code was gone. Strange though!!

This same thing happened next day too, so what i did is reinstall my ReadyAPI and cleaned all the cache and Temo Memory, and as of now it is working fine 🙂

 And answer to your question i think there is some kind of defect by which it reverting some things, so we can't do any such thing to save tasks

[Said]

---

@HimanshuTayal wrote:
This same thing happened next day too, so what i did is reinstall my ReadyAPI and cleaned all the cache and Temo Memory, and as of now it is working fine 🙂

---

Where / how did you cleaned the cache? And what is Temo Memory?

Thanks in advance!

[HimanshuTayal]

Sorry it's Typo, it's Temp Memory.

To clean i installed CCleaner software, it did by itself 🙂

[Olga_T]

Hi all,

Thank you everyone for sharing your expertise, it is much appreciated!

@Said has any advice help you? Does ReadyAPI work fine for you now?

[Said]

@Olga_T

Thank you for your interest in this issue. The issue is stil open. I am working with my IT dept to find a solution for this issue. I will keep you all posted

[Said · Accepted solution]

Together with IT-dept we have found a way to preventing this issue from happening

To work with ReadyAPI we log on a different machine with remote desktop connection. By making me administrator on this machine the issue no longer occurs. I share this to others that might have the same issue and for Smartbear, to help them in analysing this issue.

[Olga_T]

Thanks for sharing the solution with the Community, @Said!