Contributions
Re: TestExecute 14 behavior change?
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.2KViews1like1CommentRe: TestExecute 14 behavior change?
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.2KViews0likes3CommentsTestExecute 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 that once I upgraded one of my Jenkins nodes to TestExecute 14, the jobs on it started failing. The test itself is executing successfully. The part of the job that is failing is our custom logout script that runs in post build. It appears that when TestExecute 14 has completed running a test, it is logging the interactive user session out. Which is awesome, but I can find no documentation anywhere that says this was a change. I have read the release notes for TestComplete/TestExecute 14 as well as the release notes for the TestComplete Jenkins plugin and can find no mention of this. Before we start going through hundreds of Jenkins jobs and removing our custom logout script, I would like verification that this is in fact a new feature that we can rely on rather than our script. I would also like to know if there is a switch somewhere that would allow you to toggle this behavior. I can't think of a scenario at the moment, but there may be occassions where you do not want this to happen. Thanks!Solved2.2KViews0likes5CommentsRe: Script Extension Help
Robert, I have started trying toadd the various parts of the actual routines since apparently the stub records don't work. I am now returning the boolean as you suggested and referenced in the document, but TestComplete is still crashing. I have attached my updated files. I still haven't added the code that would run on execution, butthat should not be relevant to testing if this will import.2KViews0likes5CommentsRe: Script Extension Help
Thank you for the reply. Currently, there is non functionality of my script extension, because when I try to enable anything TestComplete just crashes on me. Again, I am sure I am doing something wrong, but can't seem to determine exactly what. Let me describe what we are wanting to do as their may be a better way to do this than the path I am trying to go down. Goal: Produce a text based log file which we can upload as an artifact into our change system that indicates that the test ran successfully. Our change system will not allow large files or MHT extensions to be uploaded into it. I wrote a function that writes out to a text log file that we can upload as an artifact. It functions much like the existing Log.Message function, but instead of writing into the TestComplete log, it just writes into a standard text file. We are then putting this logging function before and after a checkpoint. Indicating that we are attempting to validate the object/property. And then afterwards that we successfully validated the object/property. Because the test fails on error, what we see in the log is that we are attempting to validate, but never get a success message. This is OK, but obviously could be better. So it takes 3 steps to preform this, and the wording that each team member puts into the messages is inconsistent, therefore the output from test to test is not the same. My hope was to write a script extension that did this all in one step and the messages we write to the log file could be embedded into the extension so that they are consistent. Seemed simple enough, but I can't seem to figure out what it is I am doing wrong that is causing the script extension to crash. I even stripped it down to a very basics setup that didn't really do anything thinking a clean slate would get me started. I assume it has something to do with the relationship between the description.xml and the script file that I am just not getting.2KViews0likes10Comments