Initial setup for the UI Test with sample widget tests

[AmelBawa-msft]

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

• Closes Initial setup for the UI Test #1289
• Tests added/passed
• Documentation updated

[AmelBawa-msft]

Can we use AccessibilityId for adaptive cards forms?

CC: @krschau @ujjwalchadha

[florelis]

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

[AmelBawa-msft]

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.

[AmelBawa-msft]

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