Tests

Accessing the configuration

❌ Don't: Obtain UiPlayer configuration values from the .runsettings file

Obtaining test configuration values via UiTest is unnecessary, expensive and bug-prone. You may accidentally get stale information if any configuration values are overwritten outside the .runsettings file.

private void TestScript(UiExecutionController controller)
{
    // this is a bad idea
    var params = this.GetParametersFromRunSettings();
}

✔️ Do: Obtain own parameters from the .runsettings file

Obtaining your own defined parameters using the .runsettings is ok. For example, a database string, or any parameter that is not test configuration related.

✔️ Do: Avoid asking for the configuration values in your code

The configuration should never get in the way of your test cases. You should be able to set and forget it.

✔️ Do: Use the controller's configuration

If absolutely necessary, you can access the current configuration on the controller object:

private void TestScript(UiExecutionController controller)
{
    // configuration values are exposed as properties here
    UiPlayerConfiguration config = controller.Configuration;
}

Visual vs. Functional

❌ Don't: Mix visual equivalence and functional equivalence tests

Adding non-functional validations to functional tests is confusing and unnecessary. Some examples of non-functional validations include:

• Validating UI elements' properties (text, visible, etc.) which are not relevant to the test being performed.

• Performing image comparisons of UI elements prior to executing the test case steps.

✔️ Do: Separate visual and functional tests

Keep both types of tests separate via folders or projects to avoid confusion amongst your peers and easily identify test failures on CI.

Documenting test case methods

❌ Don't: Use Scenario as a test case summary

Scenario has a particular meaning within Behavior Driven Development. If you're not using BDD, you should not use Scenarios.

[TestMethod]
[Scenario("Test that tests things.")]
public void TestCase()
{
    // steps...
}

✔️ Do: Use an XML summary comment

If you need to provide a summary of the test case and you're not using BDD, use a traditional XML summary comment.

/// <summary>
/// Test that tests things.
/// </summary>
[TestMethod]
public void TestCase()
{
    // steps...
}

✔️ Do: Use the test method string to document test case methods

The TestMethod attribute from MsTest framework handles a string that you can use as identifier for the test.

[TestMethod("Test that tests things.")]
public void TestCase()
{
    // steps...
}

Interacting with different technologies in a UITest script

❌ Don't: Use UIPlayer's Instance directly

UITest is intended to hide the specifics of UIPlayer from users.

// TestCaseClass.cs

private UiPlayerConfiguration WebConfiguration = new()
{
    Technology = Technology.Web,
    // more configuration...
}

private UiPlayerConfiguration DesktopConfiguration = new()
{
    Technology = Technology.Desktop,
    // more configuration...
}

[TestMethod]
public void TestCase()
{
    this.Execute(this.TestCaseScript, this.WebConfiguration)
}

private void TestCaseScript(UiExecutionController controller)
{
    // no need for this!
    UiPlayer.Instance.Execute(DesktopConfiguration, DesktopScript);
}

private void DesktopScript(UiExecutionController controller)
{
    // desktop steps here...
}

✔️ Do: Use this.Execute

You can use this.Execute within another method invoked the same way.

// TestCaseClass.cs

private UiPlayerConfiguration WebConfiguration = new()
{
    Technology = Technology.Web,
    // more configuration...
}

private UiPlayerConfiguration DesktopConfiguration = new()
{
    Technology = Technology.Desktop,
    // more configuration...
}

[TestMethod]
public void TestCase()
{
    this.Execute(this.TestCaseScript, this.WebConfiguration)
}

private void TestCaseScript(UiExecutionController controller)
{
    this.Execute(DesktopScript, DesktopConfiguration);
}

private void DesktopScript(UiExecutionController controller)
{
    // desktop steps here...
}

✔️ Do: Create a new context with a different technology

Creating a new context can also be used to swap between technologies.

// TestCaseClass.cs

private UiPlayerConfiguration WebConfiguration = new()
{
    Technology = Technology.Web,
    // more configuration...
}

private UiPlayerConfiguration DesktopConfiguration = new()
{
    Technology = Technology.Desktop,
    // more configuration...
}

[TestMethod]
public void TestCase()
{
    this.Execute(this.TestCaseScript, this.WebConfiguration)
}

private void TestCaseScript(UiExecutionController controller)
{
    using (controller.Configuration.CreateContext(mySettings))
    {
        this.DesktopScript(controller);
    }
}

private void DesktopScript(UiExecutionController controller)
{
    // desktop steps here...
}