Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LR] APP robot capabilities on JSON file #2520

Open
ittaLaRedoute opened this issue Feb 5, 2024 · 1 comment
Open

[LR] APP robot capabilities on JSON file #2520

ittaLaRedoute opened this issue Feb 5, 2024 · 1 comment

Comments

@ittaLaRedoute
Copy link

Hello,
Currently Cerberus manage robot capabilities for the application (Appium and Selenium) based on invariants (then the JSON file creation is managed by Cerberus).
On version Cerberus 4.17, the following JSON file is generated:

{
  "FinalCapabilities": {
        (…)
    },
  "RequestedCapabilities": {
        (…)
  }
}

This has some limitation because, in the case of Appium, the capabilities has evolved and the current expected JSON file as some differences (and some capabilities are not applied currently): https://appium.io/docs/en/2.4/guides/settings/#

Would it be possible to have instead a JSON field to define the capabilities? This would work also with Selenium and could help the implementation of Cerberus to Appium 2.0

@vertigo17
Copy link
Member

Not sure why you mention the Robot.json file generated by Cerberus.
That file is generated on the execution in order to 1/ keep a trace of the capabilities asked by the user inside the robot and 2/ provide the information of what are the real capabilities provided to Selenium/Appium for debug purpose.

I understand that what you would like is more to: feed the capabilities from a JSON file rather than a GUI ?

That will require to adapt this modal:

image

Correct ?

I don't see any limitation on feeding that from a key/value GUI controled screen.
Can you be more precise on those ?

The complexity of replacing GUI by a free json file is that it make that definition more risky as format will have to be mastered by the user and list of capabilities no longer proposed from the invariant list.
This is to me less user friendly and risky for functional users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants