-
Notifications
You must be signed in to change notification settings - Fork 357
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
Initial setup for the UI Test with sample widget tests #1278
Conversation
|
||
// Wait for the widget to be rendered before configuring and | ||
// pinning it | ||
// TODO: Can we use AccessibilityId for adaptive cards forms? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use AccessibilityId for adaptive cards forms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the concern with using AccessibilityId? That it may change if Adaptive Cards gets updated? Or that we don't know the ID?
If it's about the later, I believe you can find it with Accessibility Insights or Inspect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've extracted the class name from the Accessibility Insights tool since I couldn't find the AutomationId. Both concerns are correct, if the JSON template changes in the future we need to reuse the Accessibility Insights tool to inspect the components that were rendered from the JSON template file and re-find the elements. Ideally, controlling the automation/accessibility ID is more forward compatible in case the template was modified in the future.
"PackageFamilyName": "Microsoft.Windows.DevHome.Dev_8wekyb3d8bbwe", | ||
"Widget": { | ||
"IdPrefix": "Microsoft.Windows.DevHome.Dev_8wekyb3d8bbwe", | ||
"Provider": "CoreWidgetProvider" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not very familiar with the widget provider, so I am not sure if there's value in adding the CoreWidgetProvider
here (let me know if you have preference). This and the IdPrefix
are used to determine which NavigationItem to click in the add widget dialog, which allows UI testing Dev Home (Canary) with Dev Home (Dev) widgets.
More details: AddWidgetDialog.cs
Summary of the pull request
tools
UI tests csproj in favor of the one in the root dir: No need to share code between csproj, less test dlls, and solve ambiguity for deciding where test that cross domains should be authoredInitial Design (Simplified. More details in the code)
UI test example:
References and relevant issues
Detailed description of the pull request / Additional comments
Validation steps performed
PR checklist