Write an MTF test case in Python

We recommend using the test runners included with the MTF toolchain for easier and quicker set up and detailed test results. For Python test cases, the appropriate test runner is XTR. For more information, you can refer to this guide: Test runner for python test cases.

Steps

First, install XTR. Follow these steps for the XTR installation: XTR test runner installation.
Next, create a Python file named after the test case name with a ‘Test’ prefix. For example, if you choose to name the test case ‘transmit_frames’, its file should be named ‘test_transmit_frames’.

Then, write your first test case following this template:

MTF / XTR test case template

class TestMyTestCase(test_fixture_name) :
    #Add the metadata

    def setup(self):
        # setup logic goes here
        pass
    def test_execute(self):
        # test case code goes here
        pass
    def teardown(self):
        # teardown logic goes here
        pass

Important

The test case should be a class that ideally has the same name as its file, and it should include the ‘Test’ prefix. For example, if the file is named ‘test_transmit_frames’, the test case class should be named ‘TestTransmitFrames’.

Test case structure

The MTF/XTR test case typically consists of 3 or 4 methods: The ‘test_execute’ method, the ‘setUp’ method , the ‘tearDown’ method and if needed the ‘parameterized’ method.

test_execute method

It is a mandatory method, usually named ‘test_execute(self)’, in which the test steps are defined.

class TestMyTestCase():

    def test_execute(self):
        pass

setUp method

It is an optional ‘setUp’ method, executed before the test to set up preconditions. It is needed if the test case requires setup steps beyond those defined in the test_fixture. In this case, additional or alternate setup steps can be specified here.

class TestMyTestCase():

    def setUp(self):
        pass

tearDown method

It is an optional ‘tearDown’ method, executed after the test to perform cleanup tasks and it adheres to the same standards as the setup function.

class TestMyTestCase():

    def tearDown(self):
        pass

parameterized method

The ‘parameterized’ method is an additional special test case method, that adds variations. In multiple scenarios, a Test case logic will remain the same, but it will need to be executed using different variables.

For example, executing the same logic on multiple channels connected to an ECU, or checking for the same conditions in a list of messages being received. To address this, instead of complicating the test case by using loops, the parameterized class method offered by XTR should be used to parameterize the test case itself.

Using this function, a list of test case alternatives will be generated and then executed using a single test case logic but with different variable names as shown in the example above.

So the function returns a list of test case alternatives, each alternative is a dictionary of class attributes that we want to assign and later use in the test case.

Also each alternative can have a special attribute called __custom_name__ which is used to alter the test case alternative name that will appear later in the results folder. This is useful when we want to specify a human readable test case name alternative instead of an index.

Test case rules

When writing an MTF test case with XTR, make sure to follow these rules so that XTR generates the best output:

The test case should inherit from either the project’s ‘TestBase’ or an appropriate test fixture, depending on its specific requirements. Refer to Create a test base file and Create a test fixture file pages for more information about these two files.

The test case should be kept straightforward and linear, avoiding loops or nested logic.
The test case should be easily human-readable, with all logic implemented in helper functions.
The test case should include test case steps to specify the actions that will be recorded in the report. Test case steps are optional within a test case. You can activate them by using the self.tc_step(step_name, step_description) method in the test case. These steps will be visible in the logs and in the HTML report.
The test case should contain assertions to verify values; if an assert fails, the test case itself fails.