Forum Discussion

DavidE's avatar
DavidE
Contributor
6 years ago

TestExecute 14 behavior change?

We are just starting to look at upgrading our environment to TestComplete/TestExecute 14.  We use Jenkins in our environment to automate running our tests and reporting results.   I have noticed ...
  • DavidE's avatar
    DavidE
    6 years ago

    Thanks for the response Robert.  I believe it to be the plugin as well because if I run the test directly from the machine using TestExecute it does not automatically log me out.  But again as I stated, I reviewed the change notes for the plugin and did not see this noted as a change.


    With regard to modifying our logout script I briefly looked into that, and unfortunately no matter what I do, the check to see if someone is logged in is throwing an error if no one is logged in that Jenkins is catching and failing the job.  I have tried to trap and handle the error, but thus far I have been unsuccessful is stopping Jenkins from flagging the job as a failure in this situation.

     

    In any case, as I was typing this I received a response from SmartBear and they confirmed that the fact that the Jenkins plugin was NOT releasing the session/logging the user out after the test and that was considered a bug.  This release resolved that issue and therefore the custom logoff script is no longer required.

  • DavidE's avatar
    DavidE
    Contributor
    6 years ago

    Marsha,

     

    I had already opened a case with SmartBear to ask that question that same morning.  Now I am almost a week later and the only response I received from them was on 3/11 acknowledging that they received my request and forwarded it on to the R&D team.

     

    So I am sitting here still waiting for an answer which I think is completely unacceptable.  We are a very fast moving group, and having to wait this long for an answer to a simple question just doesn't work.

     

    I have a hard time understanding why someone can't respond and say, "yes, that is expected behavior in TestExecute 14." or "No, this isn't expected behavior."

     

    That is all I was asking for.  Seems to me that there is a severe lack of knowledge of the product within their support team.

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      6 years ago

      I'm expecting that the behavior change is not so much in TestExecute but in the specific plugin for TestExecute/TestComplete in Jenkins.  TestExecute command line switches (which is what the plugin uses for selection and execution) contains no controls or parameters for logging in or logging out a user session on the target machine.  That's all in Jenkins and, most likely, the Jenkins plugin.

      I would say evidence points to this being a "new behavior" in that plugin implementation.  My suggestion would be to alter your own personal script you created to detect "Am I logged in?" If that returns true, then execute your custom logout code... if that returns false, skip the code and let the task finish.

      • DavidE's avatar
        DavidE
        Contributor
        6 years ago

        Thanks for the response Robert.  I believe it to be the plugin as well because if I run the test directly from the machine using TestExecute it does not automatically log me out.  But again as I stated, I reviewed the change notes for the plugin and did not see this noted as a change.


        With regard to modifying our logout script I briefly looked into that, and unfortunately no matter what I do, the check to see if someone is logged in is throwing an error if no one is logged in that Jenkins is catching and failing the job.  I have tried to trap and handle the error, but thus far I have been unsuccessful is stopping Jenkins from flagging the job as a failure in this situation.

         

        In any case, as I was typing this I received a response from SmartBear and they confirmed that the fact that the Jenkins plugin was NOT releasing the session/logging the user out after the test and that was considered a bug.  This release resolved that issue and therefore the custom logoff script is no longer required.