Writing Tests

RemotiveTopology does not enforce a specific testing framework, allowing you to use the one that best fits your needs. This also means that you are free to use whatever plugins or tooling you want when writing the tests.

This guide will help you integrate RemotiveTopology into a test environment by explaining how to set up your test context and manage input and output for the ECUs under test. You can also read the documentation on how to run a topology.

In the example code, we will work with three ECUs:

• The Body Control Module (BCM) contains the behavior model we want to test. It handles the logic.
• The Hazard Light Control unit (HLCU) is the ECU responsible for handling input from the hazard light button.
• The Front Light Control Module (FLCM) handles the front lights.
• There are two CAN networks connected the ECUs according to the image below.

Using Mocks in Testing

In a real environment, ECU inputs and outputs come from other ECUs, sensors, or physical controls such as buttons and levers. When writing tests, we can use mocks to simulate these endpoints.

Mocks allow us to simulate ECU behavior by acting as RemotiveTopology nodes that can be controlled by external code, such as a test case. They use the rest bus to send and receive messages.

Outputs can be handled similarly by adding another mock to capture incoming values within the test case.

By using mocks to replace input and output ECUs, we can control which parts of the topology to test.

In our example, we will add mocks for the SCCM and FLCM ECUs. These mocks will be used to simulate inputs and outputs for the BCM during testing.

Setting Up an Environment to Communicate with ECUs

The setup process depends on the types of nodes in the topology. For nodes implemented with the RemotiveTopology Framework, you can use the Simulation class, which is also used to implement behavioral models. Additionally, the RemoteECU class simplifies sending control messages and configurations to behavioral models.

Depending on your test framework, you can create a reusable environment to access the nodes across multiple tests. The example below uses a test context from behave, but most frameworks provide similar functionality.

from dataclasses import dataclass

import pytest
from remotivelabs.sim import Simulation
from remotivelabs.sim.test import make_environment
from remotivelabs.topology.remote_ecu import RemoteECU


@dataclass
class Context:
    bcm: RemoteECU
    hlcu: RemoteECU
    flcm: RemoteECU
    topology_env: Simulation


@pytest.fixture
async def test_context():
    # The broker URL is normally specified in the configuration
    # of your test framework
    broker_url = ...

    topology_env = await make_environment(broker_url, decode_enum=True)

    # Create remote ECUs to communicate with the nodes
    bcm = RemoteECU("bcm", broker_url=broker_url)
    hlcu = RemoteECU("hlcu", broker_url=broker_url)
    flcm = RemoteECU("flcm", broker_url=broker_url)

    # Wait until all the ECUs are up and running
    await bcm.assert_alive()
    await hlcu.assert_alive()
    await flcm.assert_alive()

    # Create context with dataclass
    context = Context(bcm=bcm, hlcu=hlcu, flcm=flcm, topology_env=topology_env)

    yield context

    # Cleanup after tests
    await topology_env.simulation.stop()

Writing tests with mocks

With the mocks running, we already did all the heavy lifting needed to write a test.

import asyncio

import pytest
from remotivelabs.topology.remote_ecu import SignalProperties

@pytest.mark.asyncio
async def test_light_turns_on_when_hazard_button_is_pressed(context):
    # We retrieve our remote ECUs from the context
    hlcu = context.hlcu
    flcm = context.flcm

    # We start sending the new signal. Note how we can
    # control the mock from the test case directly.
    await hlcu.update_rest_bus([SignalProperties(id="HazardLightButton.HazardLightButton", value=1.0)])

    # Wait a little bit for the message to propagate to the FLCM
    await asyncio.sleep(0.5)

    # Read the last value from the FLCM. We read two different signals
    values = await flcm.request_latest_values(
        [
            "TurnLightControl.RightTurnLightRequest",
            "TurnLightControl.LeftTurnLightRequest",
        ]
    )

    # Check that both front turn lights are requested to turn on.
    assert values["TurnLightControl.RightTurnLightRequest"] == 1.0
    assert values["TurnLightControl.LeftTurnLightRequest"] == 1.0