Validations

Using Assert on UI validations

❌ Don't: Use the standard Assert API for control validations

Using the standard Assert API to test UI control properties makes your tests fragile since it has no built in retrying capabilities.

Assert.AreEqual("Hello", label.Text);

✔️ Do: Use the Validate extension methods

Validate UI controls' properties via the Validate extension method. The Validate method will retry validations for you if they don't succeed right away.

using Mobilize.QualityMate.Automation.Extensions;

label.Validate(self => self.Text.Equals("Hello"));

Validating static text

❌ Don't: Validate text on labels and non-editable controls

Performing text validations for controls which will never change bloats your tests and makes them harder to understand and perform.

✔️ Do: Omit unnecessary text validations

If you're concerned about visual equivalence, then write separate tests for that purpose specifically.

Validating collections of controls

❌ Don't: Validate a list or collection of controls one by one

If the validation performed on each item is the same, adding one per item is the worst possible way to do it. It multiplies your code by the number of items.

// this is too much code!
list[0].Validate(self => self.Enabled);
list[1].Validate(self => self.Enabled);
list[2].Validate(self => self.Enabled);
list[3].Validate(self => self.Enabled);

✔️ Do: Loop through items for validations

Looping through items avoids code re-writting.

for(int i=0; i < list.Count; i++)
{
    list[i].Validate(self => self.Enabled);
}

✔️ Do: Use LINQ expressions

QualityMate exposes the IEnumerable interface for control lists and ControlCollections. Use LINQ methods to traverse them instead.

grid.Rows.All(row => row[0].Enabled);

Validating before interacting

❌ Don't: Add validations before interacting with controls that are guaranteed to be available

Adding validations prior to executing steps makes your test cases harder to follow and obscures your intent. Readers might ask questions like:

• Was this validation part of the test case?

• Why is this validated?

• Should I be adding these types of validations before every interaction?

control.Validate(self => self.Exists);
control.Validate(self => self.Visible);
control.Click();
anotherControl.Validate(self => self.Exists);
anotherControl.Validate(self => self.Visible);
anotherControl.Click();

Check our awaiting for the application page to learn about what UiPlayer waits before executing interactions.

❌ Don't: Validate that an item exists in a control's list of items before selecting it

This is unnecessary because if the item doesn't exist then the selection will fail as well:

// This validation is unnecessary because the click right after
// will fail equally if the item is not found
PageObject.ComboBox.Validate(self => self.Items.Contains("An item"));
PageObject.ComboBox.ClickItem("An item");

✔️ Do: Omit validations prior to interactions

If there's no reason for the control's state to have changed recently, there's also no reason for you to check it. Simply interact with the control normally.

control.Click();
anotherControl.Click();

✔️ Do: Add validations when a control is suspected to change state before interacting with it

If the previous step(s) changed the state of the UI and you'd like to ensure a control's properties before interacting with them, add those validations.

submitButton.Click();
newButton.Validate(self => self.Visible);
newButton.Click();

✔️ Do: Validate the item is selected after performing the selection

To check the item selection occurred as expected, you may validate it was successfully selected after selecting it:

PageObject.ComboBox.ClickItem("An item");
PageObject.ComboBox.Validate(self => self.Text == "An item");