You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 30, 2022. It is now read-only.
One hindrance with Appium is that it's "app" capability is restricted to only using absolute paths. For developing using Appium and testing native applications (iOS via XCUITest, UWP via WinAppDriver, etc.), this is a major pain when running tests between different machines as the absolute paths change. For our project, the Test projects and the application projects exist in the solution source repository, which is a supporting case for relative paths that would eliminate the need for source changes simply to run tests.
Since we are also using MAQS as an intermediary to Appium, I am proposing a feature to MAQS to either allow relative paths to the "app" capability for AppiumCapsMaqs or a separate key created to define the relative "app" path. If the latter is preferred, then the "app" capability should not be required by MAQS.
As a separate change, the "app" capability should not be required anyway as it's not required by Appium and can be omitted when launching already installed applications.
Appium still requires an absolute path for the "app" capability, when defined. To achieve this, the simplest approach would be to use System.IO.Path.GetFullPath(relativePath) and set the result to the "app" capability for Appium. I have confirmed that this approach would work on macOS as well. There may be need for logging the generated absolute path for transparency. Although, if there's an error with it, I imagine Appium would report that.
The text was updated successfully, but these errors were encountered:
In the meantime I suggest doing something like this:
// Runs before an of your tests run
[AssemblyInitialize()]
public static void AssemblyInit(TestContext context)
{
// Get the app value our to the configuration
string relativePath = Config.GetValueForSection(ConfigSection.AppiumCapsMaqs, "app");
// Convert the relative path to a non-relative path
string assemblyPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string filePathRelativeToAssembly = Path.Combine(assemblyPath, relativePath);
string normalizedPath = Path.GetFullPath(filePathRelativeToAssembly);
// Override the app path
Config.AddTestSettingValues(new Dictionary<string, string> { { "app", normalizedPath } }, ConfigSection.AppiumCapsMaqs, true);
}
This should update the path in the manor you want and also let's you add custom logic if it needs to be more complex.
One hindrance with Appium is that it's "app" capability is restricted to only using absolute paths. For developing using Appium and testing native applications (iOS via XCUITest, UWP via WinAppDriver, etc.), this is a major pain when running tests between different machines as the absolute paths change. For our project, the Test projects and the application projects exist in the solution source repository, which is a supporting case for relative paths that would eliminate the need for source changes simply to run tests.
Since we are also using MAQS as an intermediary to Appium, I am proposing a feature to MAQS to either allow relative paths to the "app" capability for AppiumCapsMaqs or a separate key created to define the relative "app" path. If the latter is preferred, then the "app" capability should not be required by MAQS.
As a separate change, the "app" capability should not be required anyway as it's not required by Appium and can be omitted when launching already installed applications.
Appium still requires an absolute path for the "app" capability, when defined. To achieve this, the simplest approach would be to use System.IO.Path.GetFullPath(relativePath) and set the result to the "app" capability for Appium. I have confirmed that this approach would work on macOS as well. There may be need for logging the generated absolute path for transparency. Although, if there's an error with it, I imagine Appium would report that.
The text was updated successfully, but these errors were encountered: