Allow set_mock_value on derived signals

[jacob720]

Currently you can't set a mock value for derived signals using set_mock_value. For testing, it would make things easier if you could mock a derived signal without having to mock the underlying signals.

Currently, calling set_mock_value(my_derived_signal) causes RuntimeError: Cannot set the value of a derived signal, set the underlying raw signals instead.

From my experience, it also doesn't work to do something like

device._raw_to_derived = MagicMock(return_value=x)

or

device.derived_signal.get_value = AsyncMock(return_value=x)

This doesn't cause an error but doesn't give you the desired value when you read the derived signal.

What I found does work is doing

device.derived_signal.read = AsyncMock(
        return_value={
            "device-derived_signal": {
                "value": x,
                "timestamp": 1763051436.7372239,
                "alarm_severity": 0,
            }
        }
    )

Acceptance Criteria

• You can call set_mock_value on a derived signal.

[coretl]

Please can you summarize why you can't mock the underlying devices instead?

[jacob720]

I can, but there are cases where that's quite a convoluted way to get the derived signal value to where you want it, and you end up testing the underlying devices, which you may not care about testing. For context, here's one of those instances DiamondLightSource/dodal#1704 (comment)

[coretl]

Hmm, I'm still not convinced this a good idea. When you connect(mock=True) a Device it mocks out all the hardware signals, which means you can then test the derived logic. If we were to always connect derived signals in mock mode then you wouldn't be able to test the logic. This leaves the option of having connect do what it does at the moment, but set_mock_value switch the signal into a super secret mock mode, so it stops responding to the underlying signal. It's not clear what happens then if you have a multi in multi out signal where some derived signals are mocked and some aren't.

I worry that this will make more confusion and require more explanation than it's worth for this particular use case.

I'll leave this open for now, but I'll need more convincing to make this happen...