Skip to content

Commit d13dc42

Browse files
Removes the mention of creating the event loop as this is now automatic (#1638)
* Removes the mention of creating the event loop as this is now automatic * Fix typo Co-authored-by: oliwenmandiamond <[email protected]> --------- Co-authored-by: oliwenmandiamond <[email protected]>
1 parent ea92977 commit d13dc42

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

docs/how-to/write-tests.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -58,9 +58,11 @@ class MyDevice(StandardReadable, Stageable):
5858

5959
In this example, we need to test the `stage` and `unstage` methods. For more complex devices, it is also a good idea to test the `read` method to confirm that we get the expected read signals back when this method is called.
6060

61-
We use [pytest](https://docs.pytest.org/en/stable/contents.html) for writing tests in dodal. A core part of this library is the use of fixtures. A fixture is a function decorated with `@pytest.fixture` that provides setup/teardown or reusable test data for your tests. It is defined once and can be reused across multiple tests. Fixtures are mainly used to define devices and then inject them into each test.
61+
We use [pytest](https://docs.pytest.org/en/stable/contents.html) for writing tests in dodal. A core part of this library is the use of fixtures. A fixture is a function decorated with `@pytest.fixture` that provides setup/teardown or reusable test data for your tests. It is defined once and can be reused across multiple tests. Fixtures are mainly used to define devices and then inject them into each test.
6262

63-
To help set up a device, they are created with the `init_devices(mock=True)` function from `ophyd_async.core`, which automatically initialises the device in mock mode. The `RunEngine` fixture is passed when creating a device to ensure there is an event loop available when connecting signals. This fixture is defined in `dodal/tests/conftest.py`, which is a special file recognised by `pytest`. It defines fixtures that are automatically available to any test in the same directory (and its subdirectories) without needing to import them. This is useful for defining common setup code once without duplicating it across test files.
63+
Common fixtures, such as the `run_engine` used in the below tests, can also be defined in `dodal/tests/conftest.py`, which is a special file recognised by `pytest`. These fixtures are automatically available to any test in the same directory (and its subdirectories) without needing to import them. This is useful for defining common setup code once without duplicating it across test files.
64+
65+
Devices are set up in the fixture using the `init_devices(mock=True)` function from `ophyd_async.core`, which automatically initialises the device in mock mode.
6466

6567
In order for `pytest` to detect something as a test, a function should begin with `test_*`. The test function should be self-descriptive about what it is testing, and it is acceptable (even encouraged) to have longer names for test functions for clarity.
6668

@@ -75,9 +77,8 @@ from ophyd_async.testing import assert_reading, get_mock_put, partial_reading
7577
from dodal.device.my_device import MyDevice
7678

7779

78-
# RunEngine is needed to make sure there is an event loop when creating device.
7980
@pytest.fixture
80-
async def sim_my_device(run_engine: RunEngine) -> MyDevice:
81+
async def sim_my_device() -> MyDevice:
8182
async with init_devices(mock=True):
8283
sim_my_device = MyDevice("TEST:")
8384
return sim_my_device
@@ -91,7 +92,6 @@ def test_my_device_stage(sim_my_device: MyDevice, run_engine: RunEngine) -> None
9192
def test_my_device_unstage(sim_my_device: MyDevice, run_engine: RunEngine) -> None:
9293
run_engine(bps.unstage(sim_my_device, wait=True), wait=True)
9394
get_mock_put(sim_my_device.signal_b).assert_called_once_with(OnOff.OFF, wait=True)
94-
9595
```
9696

9797
You should test the output of a device when the device has many signals read and you want to ensure the correct ones are read at the correct times, or when the `read` method of it or one of its signals (e.g. a DerivedSignal) requires testing. Functions are defined in `ophyd-async` to aid with this. `assert_reading` allows us to compare the readings generated from a `Readable` device to the expected results.

0 commit comments

Comments
 (0)