Extend The Framework to Fit Your Needs

To be sure that you will use BELLATRIX happily and frequently, we developed enormous ways to extend it. We have thus provided you with a wider test execution life cycle with the ability to plug-in everywhere.

Extended Test Execution Life Cycle and Plugins

Have a full control over your test execution

All test frameworks give you the possibility to execute logic at certain points before or after tests. Typically tests are placed inside test classes. The standard test workflow for MSTest and NUnit is:

1. Execute Assembly Initialize – once for the whole project
2. Execute Class Initialize – once for the test class
3. Execute Test Initialize – executed before each test
4. Execute Test
5. Execute Test Cleanup – executed after each test
6. Execute Class Cleanup – once for the test class
7. Execute Assembly Cleanup – once for the whole project

Why do you need to extend the standard workflow?

Usually, you want to use these primary methods to execute business test-related logic. Sample use cases:

  • Fail tests if not executed under certain time
  • Log test results in a 3rd party system
  • Control requests life cycle

To meet these requirements and allow you to write custom plugins, BELLATRIX comes with extended test execution life cycle. When you write a plugin, you can execute logic in various phases of the new life cycle- before TestInitialize, after TestInitialize, before TestCleanup, after TestCleanup and more.
For each test all registered plugins logic is executed. You can easily write your custom plugins. See how it is done. In BELLATRIX we have a feature called “execution time under”. You specify for the test class what is the maximal allowed test execution time if some of the tests takes longer to run- it fails automatically. This is done through test workflow plugin.

This is how we specify the maximal allowed time.

 public class MeasuredResponseTimesTests : APITest

This is part of the plugin.

public class ExecutionTimeUnderTestWorkflowPlugin : TestWorkflowPlugin
    protected override void PostTestInit(object sender, TestWorkflowPluginEventArgs e)
        // get the start time

    protected override void PostTestCleanup(object sender, TestWorkflowPluginEventArgs e)
        // total time = start time - current time
        // IF total time > specified time ===> FAIL TEST

In PostTestInit we start a stopwatch. We get the number placed inside the attribute in the PostTestCleanup method. Then stop the stopwatch and compare the actual and specified times. In case first took longer we fail the test.

API Client Hooks

Ability to execute logic between requests by creating an API client plugin.

You can execute your logic in various points, such as:

  • OnClientInitialized – executed after the API client is initialized. Here you can fine-tune the client.
  • OnRequestTimeout – executed if some of the requests time out.
  • OnMakingRequest – executed before making a request.
  • OnRequestMade – executed after the request is made.
  • OnRequestFailed – executed in case of request failure.

To create a custom plugin, you need to derive the class- ApiClientExecutionPlugin. Then you can override some of its protected methods. You can create plugins for logging the request failures or modifying the requests. The possibilities are limitless.

Here is an example of a plugin that measures the request’s execution time.

public class LogRequestTimeApiClientExecutionPlugin : ApiClientExecutionPlugin
    private Stopwatch _requestStopwatch = Stopwatch.StartNew();

    protected override void OnMakingRequest(object sender, RequestEventArgs client)
	_requestStopwatch = Stopwatch.StartNew();

    protected override void OnRequestMade(object sender, ResponseEventArgs client)
        Console.WriteLine($"Request made for {_requestStopwatch.ElapsedMilliseconds}");

The OnMakingRequest method is called before executing the request. There we start the stopwatch. After the request is completed, we stop the stopwatch and print the time taken.

Learn more

Assertion Hooks

Another way to extend BELLATRIX is to use assertions hooks.

Some of the available hooks are:

  • AssertExecutionTimeUnderEvent – an event executed before AssertExecutionTimeUnder method
  • AssertContentContainsEvent – an event executed before AssertContentContains method
  • AssertContentTypeEvent – an event executed before AssertContentType method

You need to implement the event handlers for these events and subscribe to them. You can call external logging provider, modify the response, etc.

public override void AssertContentContainsEventHandler(object sender, ApiAssertEventArgs arg)
    Debug.WriteLine($"Assert response content contains {arg.ActionValue}.");

public override void AssertContentEncodingEventHandler(object sender, ApiAssertEventArgs arg)
    Debug.WriteLine($"Assert response content encoding is equal to {arg.ActionValue}.");

In the example, Debug.WriteLine is called for each assertion event handler, printing to debug window what the method is verifying.

Learn more

    Autogerated Test Cases

    You might be interested also in our online trainings

    Learn How to write automated tests for web, desktop, mobile, or API apps using WebDriver, Appium, SpecFlow, and other industry-leading tools/frameworks.

    See Our Trainings