Skip to content
Snippets Groups Projects
Commit 918ef038 authored by Martin Christoph Hierholzer's avatar Martin Christoph Hierholzer
Browse files

fix testDataValidityPropagation

parent 12bcec1d
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
tests/executables_src/testDataValidityPropagation.cc
+ 80
− 30
View file @ 918ef038
......@@ -4,7 +4,6 @@
#include "Application.h"
#include "ApplicationModule.h"
#include "check_timeout.h"
#include "DeviceModule.h"
#include "ScalarAccessor.h"
#include "TestFacility.h"
......@@ -27,6 +26,8 @@
using namespace boost::unit_test_framework;
namespace ctk = ChimeraTK;
/*********************************************************************************************************************/
// A module used for initial value tests:
// It has an output which is never written to.
struct TestModule0 : ctk::ApplicationModule {
......@@ -41,6 +42,8 @@ struct TestModule0 : ctk::ApplicationModule {
}
};
/*********************************************************************************************************************/
// module for most of hte data validity propagation tests
struct TestModule1 : ctk::ApplicationModule {
using ctk::ApplicationModule::ApplicationModule;
......@@ -78,6 +81,8 @@ struct TestModule1 : ctk::ApplicationModule {
}
};
/*********************************************************************************************************************/
struct TestModule2 : ctk::ApplicationModule {
using ctk::ApplicationModule::ApplicationModule;
ctk::ScalarPushInput<int> i1{this, "i1", "", ""};
......@@ -95,6 +100,8 @@ struct TestModule2 : ctk::ApplicationModule {
}
};
/*********************************************************************************************************************/
struct TriggerModule : ctk::ApplicationModule {
using ctk::ApplicationModule::ApplicationModule;
ctk::ScalarOutput<int> o1{this, "o1", "", ""};
......@@ -109,10 +116,12 @@ struct TriggerModule : ctk::ApplicationModule {
}
};
/*********************************************************************************************************************/
template<typename ModuleT>
struct TestApplication1 : ctk::Application {
TestApplication1() : Application("testSuite") {}
~TestApplication1() { shutdown(); }
~TestApplication1() override { shutdown(); }
ModuleT mod{this, "m1", ""};
......@@ -129,28 +138,21 @@ struct TestApplication1 : ctk::Application {
}
};
// BOOST_AUTO_TEST_SUITE(dataValidityPropagation)
/*********************************************************************************************************************/
struct TestApplication3 : ctk::Application {
constexpr static char const* ExceptionDummyCDD = "(ExceptionDummy?map=testDataValidityPropagation2.map)";
TestApplication3() : Application("testPartiallyInvalidDevice") {}
~TestApplication3() { shutdown(); }
~TestApplication3() override { shutdown(); }
TriggerModule m2{this, "m2", ""};
ctk::DeviceModule device1{this, ExceptionDummyCDD, "/m2/o1"};
// ctk::DeviceModule device1{this, ExceptionDummyCDD};
// void defineConnections() override {
// // use manual connection setup instead of ConnectingDeviceModule.
// // note, differently from automatic connection setup, registers contain . and not / as separator
// auto pollInput1 = device1("dev.i1", typeid(int), 1, ChimeraTK::UpdateMode::poll);
// auto pollInput2 = device1("dev.i2", typeid(int), 1, ChimeraTK::UpdateMode::poll);
// auto trigger = m2("o1");
// pollInput1[trigger] >> cs("dev.i1", typeid(int));
// pollInput2[trigger] >> cs("dev.i2", typeid(int));
// }
};
/*********************************************************************************************************************/
/*********************************************************************************************************************/
/**
* tests the ExceptionDummyPollDecorator of the ExceptionDummyBackend, which provides a way for
* forcing individual (poll-type) device outputs to DataValidity=faulty
......@@ -158,7 +160,6 @@ struct TestApplication3 : ctk::Application {
BOOST_AUTO_TEST_CASE(testDataValidity_exceptionDummy) {
TestApplication3 app;
ctk::TestFacility test{app};
// app.dumpConnections();
ChimeraTK::Device dev(TestApplication3::ExceptionDummyCDD);
......@@ -179,24 +180,30 @@ BOOST_AUTO_TEST_CASE(testDataValidity_exceptionDummy) {
BOOST_CHECK(devI2.dataValidity() == ctk::DataValidity::ok);
}
/*********************************************************************************************************************/
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_1_1 \ref dataValidity_1_1 "1.1"
* In ApplicationCore each variable has a data validiy flag attached to it. DataValidity can be 'ok' or 'faulty'.
*
* Explicit test does not make sense since this is clear if this suite compiles,
* i.e. expressions testmod1.i1.dataValidity() and testmod1.o1.dataValidity();
* Explicit test does not make sense since this is clear if this suite compiles, i.e. expressions
* testmod1.i1.dataValidity() and testmod1.o1.dataValidity();
*/
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_1_2 \ref dataValidity_1_2 "1.2"
* This flag is automatically propagated: If any of the inputs of an ApplicationModule is faulty,
* the data validity of the module becomes faulty, which means all outputs of this module will automatically be
* flagged as faulty.
* Fan-outs might be special cases (see 2.4).
* This flag is automatically propagated: If any of the inputs of an ApplicationModule is faulty, the data validity of
* the module becomes faulty, which means all outputs of this module will automatically be flagged as faulty. Fan-outs
* might be special cases (see 2.4).
*
* See \ref testDataValidity_2_3_3
*/
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_1_3 \ref dataValidity_1_3 "1.3"
* If a device is in error state, all variables which are read from it shall be marked as 'faulty'. This flag is then
......@@ -221,6 +228,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_1_3) {
// redmine issue: #8550
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_1_4 \ref dataValidity_1_4 "1.4"
* The user code has the possibility to query the data validity of the module
......@@ -228,6 +237,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_1_3) {
* No explicit test, if test suite compiles it's ok.
*/
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_1_5 \ref dataValidity_1_5 "1.5"
* The user code has the possibility to set the data validity of the module to 'faulty'. However, the user code cannot
......@@ -239,17 +250,14 @@ BOOST_AUTO_TEST_CASE(testDataValidity_1_3) {
*
*/
/*********************************************************************************************************************/
/**
* app with two chained modules, for \ref testDataValidity_1_6
*/
struct TestApplication16 : ctk::Application {
TestApplication16() : Application("testSuite") {}
~TestApplication16() { shutdown(); }
/*void defineConnections() {
mod1("o1") >> mod2("i1");
findTag(".*").connectTo(cs);
}*/
~TestApplication16() override { shutdown(); }
TestModule1 mod1{this, "m1", ""};
TestModule1 mod2{this, "m2", ""};
......@@ -262,10 +270,14 @@ struct TestApplication16 : ctk::Application {
*/
BOOST_AUTO_TEST_CASE(testDataValidity_1_6) {
TestApplication16 app;
app.mod2.i1 = {&app.mod2, "/m1/o1", "", ""};
app.mod1.outputValidity = ctk::DataValidity::faulty;
app.mod2.outputValidity = ctk::DataValidity::ok;
ctk::TestFacility test{app};
app.mod1.o1.write(); // satisfy initial value
// app.dumpConnections();
auto input = test.getScalar<int>("/m1/i1");
auto result = test.getScalar<int>("/m2/o1");
......@@ -282,6 +294,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_1_6) {
BOOST_CHECK(result.dataValidity() == ctk::DataValidity::faulty);
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_1_7 \ref dataValidity_1_7 "1.7"
* The user code can get the data validity flag of individual inputs and take special actions.
......@@ -289,6 +303,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_1_6) {
* No explicit test required.
*/
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_1_8 \ref dataValidity_1_8 "1.8"
* The data validity of receiving variables is set to 'faulty' on construction. Like this, data is marked as faulty as
......@@ -308,6 +324,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_1_8) {
BOOST_CHECK(o0.dataValidity() == ctk::DataValidity::faulty);
}
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_1_1 \ref dataValidity_2_1_1 "2.1.1"
* Each input and each output of a module (or fan out) is decorated with a MetaDataPropagatingRegisterDecorator
......@@ -335,14 +353,17 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_1_1) {
BOOST_CHECK(app.mod.getDataValidity() == ctk::DataValidity::faulty);
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_1_2 \ref dataValidity_2_1_2 "2.1.2"
* The decorator knows about the module it is connected to. It is called the 'owner'.
*
* There is no public function for getting the owner, but implicitly this was
* tested in \ref testDataValidity_2_1_1.
* There is no public function for getting the owner, but implicitly this was tested in \ref testDataValidity_2_1_1.
*/
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_1_3 \ref dataValidity_2_1_3 "2.1.3"
* **read:** For each read operation it checks the incoming data validity and increases/decreases the data fault
......@@ -372,6 +393,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_1_3) {
BOOST_CHECK(app.mod.decCalled == 1);
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_1_5 \ref dataValidity_2_1_5 "2.1.5"
* **write:** When writing, the decorator is checking the validity of the owner and the individual flag of the output
......@@ -380,6 +403,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_1_3) {
* Test ist identical to \ref testDataValidity_1_6
*/
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_3_1 \ref dataValidity_2_3_1 "2.3.1"
* Each ApplicationModule has one data fault counter variable which is increased/decreased by
......@@ -394,6 +419,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_3_1) {
BOOST_CHECK(testmod1.getDataValidity() == ctk::DataValidity::ok);
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_3_2 \ref dataValidity_2_3_2 "2.3.2"
* All inputs and outputs have a MetaDataPropagatingRegisterDecorator.
......@@ -401,6 +428,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_3_1) {
* Tested in \ref testDataValidity_2_1_1
*/
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_3_3 \ref dataValidity_2_3_3 "2.3.3"
* The main loop of the module usually does not care about data validity. If any input is invalid, all outputs are
......@@ -429,6 +458,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_3_3) {
BOOST_CHECK(oconst.readLatest() == false);
}
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_3_4 \ref dataValidity_2_3_4 "2.3.4"
* Inside the ApplicationModule main loop the module's data fault counter is accessible. The user can increment and
......@@ -454,6 +485,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_3_4) {
BOOST_CHECK(app.mod.dataValidity1 == false);
}
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_4_1 \ref dataValidity_2_4_1 "2.4.1"
* Only the push-type trigger input of the TriggerFanOut is equiped with a MetaDataPropagatingRegisterDecorator.
......@@ -478,6 +511,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_1) {
BOOST_CHECK(result1.dataValidity() == ctk::DataValidity::faulty);
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_4_2 \ref dataValidity_2_4_2 "2.4.2"
* The poll-type data inputs do not have a MetaDataPropagatingRegisterDecorator.
......@@ -485,6 +520,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_1) {
* No functionality that needs testing
*/
/*********************************************************************************************************************/
/**
* \anchor testDataValidity_2_4_3 \ref dataValidity_2_4_3 "2.4.3"
* The individual poll-type inputs propagate the data validity flag only to the corresponding outputs.
......@@ -513,6 +550,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_3) {
BOOST_CHECK(result2.dataValidity() == ctk::DataValidity::ok);
}
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_4_4 \ref dataValidity_2_4_4 "2.4.4"
* Although the trigger conceptually has data type 'void', it can also be `faulty`. An invalid trigger is processed,
......@@ -521,6 +560,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_3) {
* Already tested in \ref testDataValidity_2_4_1
*/
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_5_1 \ref dataValidity_2_5_1 "2.5.1"
* The MetaDataPropagatingRegisterDecorator is always placed *around* the ExceptionHandlingDecorator if both
......@@ -529,6 +570,9 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_3) {
*
* Already tested in \ref testDataValidity_1_3
*/
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_5_2 \ref dataValidity_2_5_2 "2.5.2"
* The first failing read returns with the old data and the 'faulty' flag. Like this the flag is propagated to the
......@@ -537,6 +581,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_3) {
* Already tested in \ref testDataValidity_1_3
*/
/*********************************************************************************************************************/
/*
* \anchor testDataValidity_2_6_1 \ref dataValidity_2_6_1 "2.6.1"
* For device variables, the requirement of setting receiving endpoints to 'faulty' on construction can not be
......@@ -546,6 +592,8 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_3) {
* Already tested in \ref testDataValidity_1_3
*/
/*********************************************************************************************************************/
/*
* \anchor testDataValidiy_3_1 \ref dataValidity_3_1 "3.1"
* The decorators which manipulate the data fault counter are responsible for counting up and down in pairs, such that
......@@ -554,4 +602,6 @@ BOOST_AUTO_TEST_CASE(testDataValidity_2_4_3) {
* Not tested since it's an implementation detail.
*/
/*********************************************************************************************************************/
// BOOST_AUTO_TEST_SUITE_END()
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

imprint | privacy | Conditions of Use