Forum Discussion

ucuber's avatar
ucuber
Occasional Contributor
6 years ago

Remote Error Catching

Hi *,

yesterday I asked how to signal the fail of a remote test to a controlling instance?

I solved it by setting a flag-variable on networksuite level by onerror_log event handler in the remote test.

On the controlling instance I look up whether it was set and if, I do what has to be done.

Seems not so elegant to me, if anyone has an idea how to perform this with built-in features of tc?

Regards

Ulrich

  • AlexKaras's avatar
    AlexKaras
    6 years ago

    Hi Ulrich,

     

    Hope, I got your problem right...

    Well, you may get the state of every job via its properties - https://support.smartbear.com/testcomplete/docs/reference/project-objects/items/network-suite/job/state.html

     

    As for the status (I guess that in the given case you understand it like passed/failed)...

    On the one hand, it might be handy if job.Run() returns something like this.

    But on the other hand:

    -- While TestComplete well can be used for integration testing, its primary area is end-to-end testing (https://automationpanda.com/2017/10/14/bdd-101-unit-integration-and-end-to-end-tests/);

    -- In the end-to-end testing we are checking not that some operation works, but that some task can be done. It is possible that some problem occurs while doing the task and this problem definitely must be reported to the test log. But if the task can be done, then it should be reported as 'passed with problems'. And then it is a job for the relevant people to triage the severity of the reported problem.

    With the above in mind, I am not sure that simple Pass/Fail status is really meaningful result for the end-to-end tests.

     

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    6 years ago

    Hi Ulrich,

     

    > yesterday I asked [...]

    Hm-m... Can you post a link to the question as I don't see it in this board...

     

    > on networksuite level 

    NetworkSuite variables are the means to data exchange between tasks running on different machines (including controlling one) for the Network Suite. So everything seems to be fine here.

    What you don't like in your approach? What built-in features you are expecting to use/exist?

     

    • ucuber's avatar
      ucuber
      Occasional Contributor
      6 years ago

      Hi Alex,

       

      my first post was a little bit lengthy, so I shortend it. So in principle it is the original post here. I will make this clearer in the o.p.

       

      Why I don't like my approach:

       

      I thought there would be some "automagic" from TC that makes it possible to ask for the return status of a remote job. Something one knows from parallel processing, kind of "spawn-wait" mechanism.

       

      The benefit from s.th. like this might be one does not have to setup all the networksuite variable stuff for sending return or status info between remote test and the controller. Especially if you have plenty of remotes running parallel it is a little bit tricky to sync it all - what will now come up as the next task for me :-/.

       

      Regards

       

      Ulrich

      • AlexKaras's avatar
        AlexKaras
        Champion Level 3
        6 years ago

        Hi Ulrich,

         

        Hope, I got your problem right...

        Well, you may get the state of every job via its properties - https://support.smartbear.com/testcomplete/docs/reference/project-objects/items/network-suite/job/state.html

         

        As for the status (I guess that in the given case you understand it like passed/failed)...

        On the one hand, it might be handy if job.Run() returns something like this.

        But on the other hand:

        -- While TestComplete well can be used for integration testing, its primary area is end-to-end testing (https://automationpanda.com/2017/10/14/bdd-101-unit-integration-and-end-to-end-tests/);

        -- In the end-to-end testing we are checking not that some operation works, but that some task can be done. It is possible that some problem occurs while doing the task and this problem definitely must be reported to the test log. But if the task can be done, then it should be reported as 'passed with problems'. And then it is a job for the relevant people to triage the severity of the reported problem.

        With the above in mind, I am not sure that simple Pass/Fail status is really meaningful result for the end-to-end tests.