Test double buffer accessor ns

[nshehz]

No description provided.

[killenb]

You put a lot of effort in identifying the test cases that need to be covered. However, basically all tests have issues:

• They are not testing along the public API and will break when refactoring
• They are often testing implementation details instead of wanted behaviour. Some do not have any logical test coverage at all.
• Many tests are fully covered by the UnifiedBackendTest, and most can be implemented to be checked there. There are only two test cases which do not work out of the box
  • The test with two accessors locking each other in different threads
  • The test that the double buffering is turned off while reading (is missing a callback in the dummy. We should extend the dummy here. I was just missing this in a test this week, but could work around it because my accessors are writeable. There is a write callback). But it's also not cleanly testable here without the callback.

We should move all tests that can be covered by the UnifiedBackendTest to a testDoubleBufferAccessorUnified, and only have the ones that cannot be handles there in this dedicated test.

• One test case is missing: Two different registers which are using the same double buffering handshare (e.g. FD and the according macro pulse number). This will also be a dedicated test at the moment, because the unified backend test cannot handle multiple registers.

[killenb]

Please squash all commits into one. It just adds one file. The history how this was done can be squashed.

[nshehz]

Point 1-3: Move tests covered by UnifiedBackendTest to testDoubleBufferAccessorUnified
Not done, as we discussed earlier:

The UnifiedBackendTest framework has no double buffer support whatsoever. It tests generic TransferElement behavior (read, write, version numbers, async, error handling) through simple register descriptors that provide path(), generateValue(), nChannels(), etc. DoubleBufferAccessor is fundamentally different:

• It is read-only (cannot be written)
• It has a complex handshake protocol: ENA register toggle (1->0->1) across preRead/postRead, INACTIVE_BUF_ID read for buffer selection, shared mutex coordination across accessors
• It wraps two internal sub-accessors (BUF0/BUF1) and selects between them at runtime

At least what is visible to me atm:
To support DoubleBufferAccessor in UnifiedBackendTest, we would need to:

• Add a new TestCapability flag (e.g. _doubleBuffer)
• Extend the register descriptor interface with new methods (enableRegisterPath, doubleBufferIndex, shared registers list)
• Implement 3+ new complex test methods (threading-based handshake toggle, lock contention, shared handshake verification)
• Provide backdoor HW access for verifying ENA register state

So in summary:
UnifiedBackendTest ~4000 lines of heavily templated Boost.Test code would be a significant change to the framework. The existing 4 dedicated test cases in testDoubleBufferAccessor.cc are simpler, more readable, and equally
effective at testing the double-buffer-specific behavior.

What I did instead for now:
removed 8 generic TransferElement tests that were testing interface compliance (version numbers, replaceTransferElement, data loss, etc.)
These behaviors are already tested for standard accessors via UnifiedBackendTest and have no value to test specifically for DoubleBufferAccessor.

The remaining 4 tests in testDoubleBufferAccessor.cc are:

1. test_firmware_handshake_toggle. ENA register toggling
2. test_transfer_lock_blocks_other_accessor. mutex contention
3. test_shared_handshake_two_registers. shared handshake (new)
4. test_buffer_selection_current_buffer_1. opposite buffer path (new)

Point 4: The test with two accessors locking each other
Kept as test_transfer_lock_blocks_other_accessor. This is one of the two dedicated tests that cannot be handled by UnifiedBackendTest.

Point 5: The test that double buffering is turned off while reading
Kept as test_firmware_handshake_toggle. This is the second dedicated test. It tests the ENA register handshake (set to 1 in constructor, 0 in preRead, 1 in postRead) which is the core protocol of DoubleBufferAccessor.

Point 6: Move all tests that can be covered by UnifiedBackendTest
See point 1-3 above. Not applicable because UnifiedBackendTest lacks double buffer support.

Point 7: One test case is missing: two different registers sharing the same double buffering handshake
Added as test_shared_handshake_two_registers. Tests that DAQ.FD and DAQ.MACRO_PULSE_NUMBER (both using handshake index 1) properly block each other via the shared mutex.

N.B: I'll squash the changes once done.

[mhier]

So in summary: UnifiedBackendTest ~4000 lines of heavily templated Boost.Test code would be a significant change to the framework.

Just a comment without consequence right now: Adding the backdoor would be possible in the UnifiedBackendTest as it currently is, maybe in worst case a special DummyBackend with hooks on the relevant registers would be needed. I am not saying you should do this now, this is a complex task and maybe we should improve the UnifiedBackendTest first to make these things easier...

Point 4: The test with two accessors locking each other Kept as test_transfer_lock_blocks_other_accessor. This is one of the two dedicated tests that cannot be handled by UnifiedBackendTest.

True, the UnifiedBackendTest currently cannot do tests with concurrent accessor use.

happy vacation :-)