1.2. Test Actions and Functions - deftpack/testautomation GitHub Wiki

Test actions are an extra abstraction layer in the test execution chain. The main purpose is to create reusable components that encapsulates test steps that form a logical group. Views should not contain any logic, and not for any chance any assertion. Test actions are designed to do the act and assert parts of the tests.

Let's imagine that we want to test a site which requires authentication. Repeating the logic for logging in a user is far from being optimal. In order to make this piece of code common, a test action can be created. Quite often an action is not even in the aim of the current test, it it something which is more of an arrange part of the test. Doing this type of abstraction helps us to be able focus on the current test's goal.

Test Action has to inherit from DeftPack.TestAutomation.Functional.Evaluation.TestAction. At the same time the executing framework requires the actions to be decorated with the TestActionDescription. The description makes the actions self documenting and also represent the output in the reports. It contains four parts.

• Action Summary meant to be describing the main aim of the given action
• Expected Result explains what should happen if the action is executed successfully
• Success Message gives an opportunity to include more detail about the execution. You can add the standard .NET place holder ("{0}"), to add any dynamically generated information. This place holder will be replaced with content coming from the ExtraMessage property. This way you print out things like usernames, ids or any specific info that could be necessary to understand the actual test run.
• Failed Message is supposed to mainly describe the impact of the failed test action. It also gives the opportunity to display the exception message similar to the success message with the standard place holder. Any exception's message thrown while executing the action, would be placed there.

using DeftPack.TestAutomation.Functional.Evaluation;

[TestActionDescription(
        ActionSummary = "Login with a given customer, 
                         so it can access the account management section.",
        ExpectedResult = "Navigating to the welcome page is successful, 
                          and username is displayed.",
        SuccessMessage = "Logged in with {0} username.",
        FailedMessage = "The customer won't be able to see or 
                         change any customer related data.")]
public class LoginCustomer: TestAction
{
    // Implementation
}

The test actions' dependencies are constructor injected. These dependencies could fall other two categories. Most of the actions works with at least one view. These are resolved by the framework (purely based on the convention that they inherit from the View base class). The second group is any required information that necessary for the execution.

public LoginCustomer(
    Welcome welcome, Login login, Home home, // All the views
    string username, string password) // Additional information
{
    // Storing them in private fields
}

The act and the assert part of the action goes into the Evaluate method (this will be invoked by the framework). To include any additional information you need to override the ExtraMessage property.

public override void Evaluate()
{
    PatientAssert.IsTrue(() => _welcomeView.IsLoaded);
    // ...
}

public override string ExtraMessage
{
    get { return _username; }
}

The difference between test actions and test functions that the latter one could also return a model. This can be useful when information needs to flow between actions without coupling them together. As a result you have to override the CreateModel function instead of the Evaluate method. The framework will call that and set the Model property to the result.

public class SearchArticles: TestFunction<SearchResultsModel>
{
    public SearchResultsModel CreateModel()
    {
        return new SearchResultsModel(/* results */);
    }
}