Adding RestApiUtils and a pre driver launch checkup, if device is inUse, unavailable, not connected then not trying to starting the driver #50
Conversation
…r before launch the driver
|
Sure no problem Jack. Feel free. Yea let’s discuss on the thread ;) I rather have it fail the test case saying no device to execute the test. I want the customer to complain that their tests are not running and fix their broken framework. But again, let’s open it for discussion on the thread. Thanks, -Raj From: Jack Deng Hi Raj, Thanks for reply, that’s actually a problem with this solution. I am wondering what is the best way to exit the whole testset gracefully from the Listener? BTW, do you mind if I will post your email to the pull request discussion thread? Thanks From: Raj Pasupathy rajp@perfectomobile.com Thanks Jack, I think this is great. Good to know! Questions: Best, |
|
Hi Eyal Thanks for the input, I am thinking to add a switch to this so to have it work as an optional feature. I will make sure it will be turned off by default. Of course it will up to Hadas and Kulin to decide if it’s allowed to be merged to the master. Please add further comments to the pull requests so they will all be tracked and discussed Thanks — Hi Jack, Yes, I also thought that probably the new DZ will solve this issue 👌. I am new at Perfecto so maybe I am talking nonsense but if this solution is only for your client why you push it to the master and not having your own branch (especially if you said it is temporary)? Thanks and regards, |
|
Thanks Jack for creating the pull request. I agree with Raj that we should want the tests to fail by default so that the clients will be able to track all the failures, including the device failures in their reports. However, I like the idea of creating a switch so that for specific clients we can remove the noise in the reports if required. One thing that we need to check is how to skip the entire test suite of the device is not available. Give me some time to check this implementation with some dry runs and understand the use case that you have described so I can provide better inputs. I will also explore the part of skipping the tests in case the driver is not initialized. |
|
Thanks Kulin, I will also try to find a better way to exit the suite gracefully, will get back to you later this week. |
if driver_availability_check=yes is set in applications.properties then invoke this checkup if driver_availability_check is not set, or set to anything but yes, then ignore the checkup
|
From: David Reed davidre@perfectomobile.com Jack, I'm curious about how this practice eliminates the install time from the equation. A new build of an app still requires installation at some point. Are they just lacking the concept of test suite? Also, now, if the driver fails to initialize, what happens to the rest of the intended execution? Is it not an actual failure? This seems more like something that belongs above the individual test execution level, probably at the test suite level or in the orchestration engine, like Jenkins, or even higher. This change would seem to introduce a lot more invisible fragility in the test suite, since individual tests are now failing to launch entirely just because they're poorly written. Wouldn't it be better to configure this as a suite dependency option? Connection sharing for a suite would also achieve the goal of reducing reinstallation time, no? David Reed |
|
Hi Jack, Sorry for the delay. I think we can add this code. Just a quick question, will all the test scenarios show as failed if the device is not available? Do you think we should try for the device to be available for some time some sort of device availability timeout? |
|
Hi Kulin, yes it will retry several times before reaching the driver launch time limit, then will give up the driver launch and therefore fail the rest tests which rely on the driver. I suggest to hold for this pull request , I plan to add some built in tests to test the RestApi features every time it gets build. Thanks for taking time review the changes:) |
2. Added LoadCert() to RestAPIUtils to over come the building slaves/Agents which does not have proper Perfecto.com cert 3. Added a keystore to resources folder to allow loadcert to activate Perfecto.com cert to the httpclient to use when sending http requests to perfecto RestApis
from within the qunatum