benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/tests/operation/bugs/hello-bug-test.cpp

55 lines
1.1 KiB
C++
Raw Permalink Normal View History

TDBS (test driven brain storming) :-)
2007-09-03 02:33:47 +02:00
/*
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
HelloBug(Test) - placeholder for running bug regression tests
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)
2008, Christian Thaeter <ct@pipapo.org>
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
* *****************************************************************/
TDBS (test driven brain storming) :-)
2007-09-03 02:33:47 +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 hello-bug-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 HelloBug_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
*/
TDBS (test driven brain storming) :-)
2007-09-03 02:33:47 +02:00
finish common->lib transition for the tests
2008-12-18 04:47:41 +01:00
#include "lib/test/run.hpp"
TDBS (test driven brain storming) :-)
2007-09-03 02:33:47 +02:00
#include <iostream>
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
using std::cerr;
using std::endl;
TDBS (test driven brain storming) :-)
2007-09-03 02:33:47 +02:00
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
namespace lumiera{
namespace test {
WIP set up some new tests for brainstorming...
2009-08-31 00:49:08 +02:00
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
/**************************************//**
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
* @todo come up with some more bugs
* @test cover known regressions
WIP set up some new tests for brainstorming...
2009-08-31 00:49:08 +02:00
*/
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
class HelloBug_test
: public Test
TDBS (test driven brain storming) :-)
2007-09-03 02:33:47 +02:00
{
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
virtual void
mass clean-up: adapt usage of std::cout pretty much everywhere - remove unnecessary includes - expunge all remaining usages of boost::format - able to leave out the expliti string(elm) in output - drop various operator<<, since we're now picking up custom string conversions automatically - delete diagnostics headers, which are now largely superfluous - use newer helper functions occasionally I didn't blindly change any usage of <iostream> though; sometimes, just using the output streams right away seems adequate.
2016-01-07 03:58:29 +01:00
run (Arg)
{
cerr << "hello sunshine, no bugs whatsoever" <<endl;
}
WIP set up some new tests for brainstorming...
2009-08-31 00:49:08 +02:00
};
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
WIP set up some new tests for brainstorming...
2009-08-31 00:49:08 +02:00
/** Register this test class... */
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
LAUNCHER (HelloBug_test, "function regression");
WIP set up some new tests for brainstorming...
2009-08-31 00:49:08 +02:00
re-arrange tests according to layer structure the buildsystem will now pick up and link all test cases according to the layer, e.g. backend tests will automatically be linked against the backend + library solely.
2013-01-07 05:43:01 +01:00
}} // namespace lumiera::test
Reference in a new issue Copy permalink