Test case file

Overview

First, create a Python file that follows the config.json prefix rules. 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:

XTR test case template

#Add the metadata decorator
class TestMyTestCase(test_fixture_name) :

    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

Test case structure

The 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_method method

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

class TestMyTestCase():

    def test_method(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 class method

The ‘parameterized’ class method is an additional special test case method, that enables executing the same Test case logic with different scenarios(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 runtime test cases will be generated from a single test case logic but with different parameter names as shown in the example above.

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

XTR also provides a ParametrizationStruct dataclass which can be extended by inheretance. Test cases takes advantage of that feature to use the parametrization along with autocomplete for attribute names.

Test case rules

When writing an XTR test case 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.
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 use XTR generic apis that will be recorded and displayed in the reports mentioned in the config.
The test case should use unittest apis which signature is self.tc_step(assertion, severity: Severity, message: str, requirement: str | List[str] = None)

Note

tc_step can be addStep, assertTrue, assertFalse, assertEqual, assertNotEqual, assertIsNone, assertIsNotNone, expectTrue, expectFalse, expectEqual, expectNotEqual, expectIsNone, expectIsNotNone. Those steps will be recorded and displayed in the reports.