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

Initial setup for the UI Test with sample widget tests #1278

Merged
merged 7 commits into from
Jul 20, 2023

Conversation

AmelBawa-msft
Copy link
Contributor

@AmelBawa-msft AmelBawa-msft commented Jul 11, 2023

Summary of the pull request

  • Using Page Object pattern for simplifying UI interactions and decoupling the automation logic from the UI test logic.
  • Included UI tests for adding/removing widgets
  • Removed 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 authored

Initial Design (Simplified. More details in the code)

classDiagram
    class DevHomeSession{
        Start()
        Stop()
    }
    class DevHomeApplication{
       <<Singleton>>
        Initialize(...)
        Start()
        Stop()
        NavigateToDashboard()
        NavigateToMachineConfiguration()
        TakeScreenshot()
    }
    DevHomeApplication *-- DevHomeSession

    class ApplicationPage{
    }
    class DashboardPage{
        ClickAddWidgetButton()
        RemoveAllWidgets()
        WaitForWidgetsToBeLoaded()
    }
    class MachineConfigurationPage{
    }
    ApplicationPage <|-- DashboardPage
    ApplicationPage <|-- MachineConfigurationPage

    class PageDialog~T~{
        Parent
    }
    class AddWidgetDialog{
        AddCPUUsageWidget()
        AddGPUUsageWidget()
        AddMemoryWidget()
        AddNetworkUsageWidget()
        AddSSHWidget(...)
    }
    PageDialog <|-- AddWidgetDialog

    class DevHomeTestBase{

    }
    class WidgetTest{
        AddWidgetsTest()
        RemoveWidgetTest()
    }
    DevHomeTestBase <|-- WidgetTest
    ApplicationPage --* PageDialog
Loading

UI test example:

    [TestMethod]
    public void RemoveWidgetTest()
    {
        // Note: Test method does not know how we find elements on the UI etc...
        // It simply focuses on the test logic.

        // Arrange
        var dashboard = Application.NavigateToDashboardPage();
        dashboard.RemoveAllWidgets();

        // Act
        var initialWidgetCount = dashboard.DisplayedWidgets.Count;
        dashboard.ClickAddWidgetButton().AddNetworkUsageWidget();
        var oneWidgetCount = dashboard.DisplayedWidgets.Count;
        dashboard.RemoveAllWidgets();
        var finalWidgetCount = dashboard.DisplayedWidgets.Count;

        // Assert
        Assert.AreEqual(0, initialWidgetCount);
        Assert.AreEqual(1, oneWidgetCount);
        Assert.AreEqual(0, finalWidgetCount);
    }

References and relevant issues

Detailed description of the pull request / Additional comments

Validation steps performed

PR checklist


// Wait for the widget to be rendered before configuring and
// pinning it
// TODO: Can we use AccessibilityId for adaptive cards forms?
Copy link
Contributor Author

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?

CC: @krschau @ujjwalchadha

Copy link
Member

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

Copy link
Contributor Author

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"
Copy link
Contributor Author

@AmelBawa-msft AmelBawa-msft Jul 11, 2023

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

CC: @krschau @ujjwalchadha

@AmelBawa-msft AmelBawa-msft merged commit 634b8e4 into main Jul 20, 2023
@AmelBawa-msft AmelBawa-msft deleted the user/amelbawa-msft/ui-test branch July 20, 2023 02:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Initial setup for the UI Test
5 participants