ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/library/advice/advice-situations-test.cpp

141 lines
4.2 KiB
C++
Raw Permalink Normal View History

Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
/*
AdviceSituations(Test) - catalogue of standard Advice usage scenarios
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2010, Hermann Vosseler <Ichthyostega@web.de>
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
Doxygen: prepare all unit tests for inclusion in the documentation Doxygen will only process files with a @file documentation comment. Up to now, none of our test code has such a comment, preventing the cross-links to unit tests from working. This is unfortunate, since unit tests, and even the code comments there, can be considered as the most useful form of technical documentation. Thus I'll start an initiative to fill in those missing comments automatically
2017-02-22 01:54:20 +01:00
/** @file advice-situations-test.cpp
Doxygen: magically insert a reference to the test class this bit of Sed magic relies on the fact that we happen to write the almost correct class name of a test into the header comment. HOWTO: for F in $(find tests -type f \( -name '*.cpp' \) -exec egrep -q '§§TODO§§' {} \; -print); do sed -r -i -e' 2 {h;x;s/\s+(.+)\(Test\).*$/\\ref \1_test/;x}; /§§TODO§§/ {s/§§TODO§§//;G;s/\n//}' $F; done
2017-02-22 03:17:18 +01:00
** unit test \ref AdviceSituations_test
Doxygen: identify all files lacking a @file comment reason is, only files with a @file comment will be processed with further documentation commands. For this reason, our Doxygen documentation is lacking a lot of entries. HOWTO: find src -type f \( -name '*.cpp' -or -name '*.hpp' \) -not -exec egrep -q '\*.+@file' {} \; -print -exec sed -i -r -e'\_\*/_,$ { 1,+0 a\ \ \ /** @file §§§\ ** TODO §§§\ */ }' {} \;
2016-11-03 18:20:10 +01:00
*/
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
#include "lib/test/run.hpp"
//#include "lib/test/test-helper.hpp"
refactor namespaces for query and defaults manager
2012-12-01 08:44:07 +01:00
#include "common/advice.hpp"
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
refactor namespaces for query and defaults manager
2012-12-01 08:44:07 +01:00
namespace lumiera {
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
namespace advice {
namespace test {
namespace {
}
fix **** in doxygen comments to make them stand out more prominently, some entity comments where started with a line of starts. Unfortunately, doxygen (and javadoc) only recogise comments which are started exactly with /** This caused quite some comments to be ignored by doxygen. Credits to Hendrik Boom for spotting this problem! A workaround is to end the line of stars with *//**
2013-10-24 23:06:36 +02:00
/**************************************************************************************//**
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
* @test documentation of the fundamental usage scenarios envisioned in the Advice concept.
* This test will be augmented and completed as the Lumiera application matures.
*
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
* @todo yet more use cases to come.... ////////////////////////////////////////////////////////TICKET #335
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
*
* @see advice.hpp
* @see AdviceBasics_test
* @see AdviceConfiguration_test
*/
class AdviceSituations_test : public Test
{
virtual void
run (Arg)
{
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
pattern01_justPickAndBeHappy();
pattern02_pickIfPresent();
pattern03_installOnlyOnce();
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
TODO ("more advice usage scenarios.....?");
}
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
/** @test usage pattern 01: simply consume Advice -- irrespective if set explicitly. */
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
void
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
pattern01_justPickAndBeHappy()
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
{
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
Request<int> generic{"solution(life_and_universe_and_everything)"};
CHECK (0 == generic.getAdvice()); // the early bird gets the worm...
Provision<int> universal{"solution(life_and_universe_and_everything)"};
universal.setAdvice(5);
CHECK (5 == generic.getAdvice()); // ...while the bad girls go everywhere
universal.retractAdvice();
CHECK (0 == generic.getAdvice()); // nothing to see here, just move on
}
/** @test usage pattern 01: detect if specific advice was given. */
void
pattern02_pickIfPresent()
{
Request<int> request{"something(special)"};
CHECK (not request.isMatched());
Provision<int> info{"something(special)"};
info.setAdvice(55);
CHECK (request.isMatched());
CHECK (55 == request.getAdvice());
info.retractAdvice();
CHECK (not request.isMatched());
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
}
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
/** @test usage pattern 01: . */
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
void
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
pattern03_installOnlyOnce()
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
{
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
Provision<int> info{"something(special)"};
CHECK (not info.isGiven());
Request<int> question{"something(special)"};
CHECK (0 == question.getAdvice());
CHECK (not question.isMatched());
auto publish = [&](int i)
{
if (not info.isGiven())
info.setAdvice (i);
};
for (uint i=0; i<5; ++i)
if (i % 2)
publish (i);
CHECK (1 == question.getAdvice());
CHECK (question.isMatched());
info.retractAdvice();
CHECK (not info.isGiven());
CHECK (not question.isMatched());
}
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #335
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
/** @test usage pattern ∞ : somewhat literally fantastic */
void
check_SevenMoreWondersOfTheWorld()
{
UNIMPLEMENTED ("suitable advice to save the world");
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
}
Library: allow to check if Advice was explicitly given For context: The »Advice System« was coined a long time ago, in 2010, based on the vague impression that it might be useful for that kind of application we are about to build here. And, as can be expected, none of the usage situations envisioned at that time was brought to bear. Non the less, the facility came in handy at times, precisely because it is cross-cutting and allows to pass information without imposing any systematic relationship between the communication partners. And now we've got again such a situation. The global style manager in the UI has to build a virtual CSS path, which is needed by drawing code somewhere deep down, and we absolutely do not want to pass a reference to the style manager over 20 recursive calls. The alternatives would be (1) to turn the style manager into a public service (2) to have a static access function somewhere (3) to use a global variable. For rationale, (1) would be overblown, because we do not actually request a service to do work for us, rather we need some global piece of information. (2) would be equivalent to (1), just more confusing. And (3) is basically what the Advice system does, with the added benefit of a clear-cut service access point and a well defined lifecycle. This changeset adds the ability to check if actual Advice has been published, which allows us to invoke the (possibly expensive) GTK path building and style context building code only once.
2019-07-13 17:00:23 +02:00
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #335
Start planning the Advice implementation: skeleton of unit tests
2010-04-11 01:11:39 +02:00
// more to come.....
};
/** Register this test class... */
LAUNCHER (AdviceSituations_test, "function common");
refactor namespaces for query and defaults manager
2012-12-01 08:44:07 +01:00
}}} // namespace lumiera::advice::test
Reference in a new issue Copy permalink