It was agreed to never do this. What strings are for display only and should not be analysed, neither by tests nor by applications.

- Also removed race conditions in the test.

Print test name.

- use DummyRegister::getRawAccessor for access to backend registers.
- read and write convenience methods for rawAccessor.

- runtimeErrorHandling_testPushTypeReadNonBlocking

- Reworked header.

- Reworked header.

- Reworked Header.
- Revised variable name. version -> versionBeforeRuntimeError

fixture_with_poll_and_push_input exposes pollVariable, pushVariable as
refernce types for convenience.

- Introduced PollModule::triggerRead
- status/message process variable are now instantiated in the fixture
- use name scheme for tests:
    runtimeErrorReporting
     - runtimeErrorReporting_faultReporting

The fixture in testExceptionHandling.cc created the ChimeraTK::TestFacility before the
ChimeraTK::Application. This is unspported.

The TestFacility implicity requries an Application instance already existing before being
initialized. Changing the oder of member declaration solved the exception being thrown from the
fixture.

Initially, devices are closed and hence there is an error message. It goes away shortly when the device got opened. The new behavior is according to specification.

allows to control whether to wait for device recoveries in stepApplication

This is not correlated to the new feature implemented in this branch. It
was needed to compile this version.

Fix changes broken by renaming to ExceptionDummyBackend in DeviceAccess.

need to wait until all mainLoops() are entered, so the initial value propagation is done. Otherwise during initial value propagation values could be read from hardware which might already trigger the exception state.

one initial value was not properly waited for, and one inherent race condition is now basically ignored (with comment)

All variables from the cs to device have been initialized with a non
zero default before the test starts.

They return as soon as the condition is fulfilled, so there is no harm in having long timeouts in case the tests are successful. The only drawback is that it takes longer in case of errors.