Skip to content

Best practices to write automated tests using MTAF

lanken edited this page Mar 5, 2013 · 3 revisions

Writing good autotests (general)

1) Problem#1 in automation is coverage. Problem#2 is maintainability. Make your tests and helpers easy to read and understand. This is very important.

2) Have your own environment for running automated tests, different from the environment where your manual testers work. You must have total control of this environment, change it as needed for autotests, clean up database as often as needed, etc.

3) Don't copy (and modify) existing code. Create generic solutions.

4) Make sure that each testcase starts in the right context (browser with the required page is opened etc). In other words make sure that your setUp() or assertPreConditions() sets SUT in the expected state.

5) Don't use static pauses like sleep. Use implemented methods like waitFor* to wait for a specific element to appear, or something similar.


1) Add description of Steps and Expected Result to a test PHPdoc.

2) Select a descriptive name for a test. Name is good when it's clear what the test verifies without a need to read its PHPdoc. Long names for tests are OK.

3) Don't include raw data from UI (XPaths, URLs, values of dropdowns) into tests. They should be in UIMaps or datasets instead.

4) Avoid using static variables to pass data between tests. Use @depends instead of static variable.

5) Use tearDownAfterTest and tearDownAfterTestClass methods for clean up instead of 'special' cleanUpAfterTest() test.

6) Don't use try..catch in tests.

7) Avoid using native Selenium methods (isElementPresent for instance). Use TAF methods instead (e.g. controlIsPresent), or implement your own.


1) Add a comprehensive PHPdoc to a helper method, so that it's clear what it does and how to use it without a need to read the method code.

2) Select an informative name for a helper method. Name is good when it's not needed to read the method PHPdoc to understand what the method does. It's better to keep helper method names as short as possible.

3) To define what should be in helper, think of business actions or words that you use in a test case. E.g. you say 'Register a customer' in a tests case. Then registerCustomer would be a good helper method.

4) Our recommendation is to create helpers that you could use for both positive and negative tests. For this purpose helper should not include asserts verifying results (usually positive). E.g. registerCustomer helper should not include a verification that a customer has successfully registered. Instead, this verification should be in tests. Positive tests will have verification that a customer is successfully registered. Negative tests will have a verification that an error message appears and the customer is not added.

5) Similarly, helper methods should not contain preconditions if these preconditions can vary in different tests. E.g. to register a customer, you should navigate to the customer registration page. However, registerCustomer helper should not contain navigate method in it, since there are several ways to navigate to the page: by opening URL directly (navigate), or by clicking Register button from different pages. Opening customer registration page (by one way or another) should be done directly in tests. registerCustomer helper should only fill and submit the form.

6) There is no need to create a separate method helper if it's going to be used only one time. E.g. separate method verifyCustomerIsDeleted is not needed if it will be used only once. Instead, include this verification directly in deleteCustomer test.


1) UIMap is a map of UI elements, where a key on the left side is a name of the UIMap control representing some UI element, and a value on the right side is the corresponding locator (XPath/CSS). UIMap includes:

  • locators of text fields/ checkboxes/ drop-downs/ etc
  • messages on popups

2) Avoid hard coding XPaths in tests/helpers. All XPaths and CSS selectors should be in UIMaps.


1) Datasets contains all data that you specify/select in UI including

  • values entered into text fields
  • values selected from drop-downs/list boxes
  • checkbox state "Yes" or "No", values of radiobuttons

2) Separate tests and data. All data should be in datasets.

3) Learn how to use pre-defined parameters in datasets (such as '%randomize%'). Prefer to use parameters to generating data manually in tests.

Something went wrong with that request. Please try again.