From 17b1a5ef4b73759c2bf3756c6f421977b477cd77 Mon Sep 17 00:00:00 2001
From: vargheseg <19566373+vargheseg@users.noreply.github.com>
Date: Thu, 9 Jul 2020 12:33:40 +0200
Subject: [PATCH] testcase stubs: testExceptionHandling
---
doc/spec_exceptionHandling.dox | 2 +-
.../executables_src/testExceptionHandling.cc | 37 +++++++++++++++++++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/doc/spec_exceptionHandling.dox b/doc/spec_exceptionHandling.dox
index e6fe5889..093cf355 100644
--- a/doc/spec_exceptionHandling.dox
+++ b/doc/spec_exceptionHandling.dox
@@ -40,7 +40,7 @@ namespace ChimeraTK {
\subsection spec_exceptionHandling_behaviour_runtime_errors Runtime error handling
- \anchor b_2 2. When a ChimeraTK::runtime_error has been received by the framework (thrown by a device register accessor):
- - 2.1 The exception status is published as a process variable together with an error message.
+ - \anchor exceptionHandling_b_2_1 2.1 The exception status is published as a process variable together with an error message. [\ref testExceptionHandling_b_2_1 "T"]
- 2.1.1 The variable \c Devices/\<alias\>/status contains a boolean flag whether the device is in an error state.
- 2.1.2 The variable \c Devices/\<alias\>/message contains an error message, if the device is in an error state, or an empty string otherwise.
- \anchor b_2_2 2.2 Read operations will propagate the DataValidity::faulty flag to the owning module / fan out (without changing the actual data value of the process variable):
diff --git a/tests/executables_src/testExceptionHandling.cc b/tests/executables_src/testExceptionHandling.cc
index 6eb4c20b..126470d2 100644
--- a/tests/executables_src/testExceptionHandling.cc
+++ b/tests/executables_src/testExceptionHandling.cc
@@ -21,6 +21,43 @@
using namespace boost::unit_test_framework;
namespace ctk = ChimeraTK;
+/*
+ * This test suite checks behavior on a device related runtime error.
+ */
+BOOST_AUTO_TEST_SUITE(checkRuntimeErrorHandling)
+
+/*
+ * Verify the framework creates fault indicator process variables for a device.
+ *
+ * These are mapped on the control system as:
+ * - /Devices/<device_alias or cdd>/status
+ * - /Devices/<device_alias or cdd>/message
+ *
+ * A runtime errror on <device_alias> changes status to 1, with a non empty message
+ * string.
+ *
+ * \anchor testExceptionHandling_b_2_1 \ref exceptionHandling_b_2_1 "B.2.1"
+ */
+BOOST_FIXTURE_TEST_CASE(testFaultReporting) {}
+
+BOOST_AUTO_TEST_CASE(testBlockingRead) { // wait_for_new_data
+ // how does the api of the accessor look like
+ //device1DummyBackend["m1"]("i3")[cs("trigger", typeid(int), 1)] >> cs("i3", typeid(int), 1);
+ // make one with wait_for_new_data
+
+ // The framework decides the accessmode flags based on how the wiring looks like:
+ //
+ // we will have to make up wiring to get what we desire.
+}
+
+BOOST_AUTO_TEST_CASE(testReadLatest) {}
+
+BOOST_AUTO_TEST_CASE(testReadNonBlocking) {}
+
+BOOST_AUTO_TEST_CASE(testWrite) {}
+
+BOOST_AUTO_TEST_SUITE_END()
+
constexpr char ExceptionDummyCDD1[] = "(ExceptionDummy:1?map=test3.map)";
constexpr char ExceptionDummyCDD2[] = "(ExceptionDummy:2?map=test3.map)";
constexpr char ExceptionDummyCDD3[] = "(ExceptionDummy:3?map=test4.map)";
--
GitLab