"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "tests/acceptance/README" between
cfengine-3.12.6.tar.gz and cfengine-3.12.7.tar.gz

About: CFEngine is a configuration management system for configuring and maintaining Unix-like computers (using an own high level policy language). Community version. Community version. LTS (Long Term Support) release.

README  (cfengine-3.12.6):README  (cfengine-3.12.7)
skipping to change at line 18 skipping to change at line 18
You are encouraged to run this testsuite on any new software/hardware You are encouraged to run this testsuite on any new software/hardware
configuration, in order to configuration, in order to
* verify that CFEngine functions correctly * verify that CFEngine functions correctly
* provide developers with reproducible way to fix any problems encountered in * provide developers with reproducible way to fix any problems encountered in
new configurations / environment new configurations / environment
In case you find a bug you are encouraged to create tests in format of testsuite In case you find a bug you are encouraged to create tests in format of testsuite
which demonstrate bug found, so the test could be added to this testsuite and which demonstrate bug found, so the test could be added to this testsuite and
checked for in the future. checked for in the future.
Note that the testall script generates JUnit style XML output for parsing by CI
systems.
https://llg.cubic.org/docs/junit/
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
Preparing for running tests Preparing for running tests
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
* Compile CFEngine. * Compile CFEngine.
- It is advised to use Tokyo Cabinet as it gives much better performance in - It is advised to use Tokyo Cabinet as it gives much better performance in
test suite over Berkeley DB. test suite over Berkeley DB.
* Install fakeroot(1). If this tool is not available for your operating system, * Install fakeroot(1). If this tool is not available for your operating system,
you may use any other "fake root" environment or even sudo(1). Alternative you may use any other "fake root" environment or even sudo(1). Alternative
skipping to change at line 207 skipping to change at line 211
- test_skip_unsupported - test_skip_unsupported
Skips a test because it makes no sense on that platform (e.g. Skips a test because it makes no sense on that platform (e.g.
symbolic links on Windows). symbolic links on Windows).
- test_skip_needs_work - test_skip_needs_work
Skips a test because the test itself is not adapted to the Skips a test because the test itself is not adapted to the
platform (even if the functionality exists). platform (even if the functionality exists).
- test_soft_fail - test_soft_fail
- test_suppress_fail - test_suppress_fail
- test_flakey_fail
Runs the test, but will accept failure. Use this when there is a Runs the test, but will accept failure. Use this when there is a
real failure, but it is acceptable for the time being. This real failure, but it is acceptable for the time being. This
variable requires a meta tag on the variable set to variable requires a meta tag on the variable set to
"redmine<number>", where <number> is a Redmine issue number. "redmine<number>", where <number> is a Redmine issue number.
There is a subtle difference between the two. Soft failures will There is a subtle difference between the three. Soft failures will
not be reported as a failure in the XML output, and is not be reported as a failure in the XML output, and is
appropriate for test cases that document incoming bug reports. appropriate for test cases that document incoming bug reports.
Suppressed failures will count as a failure, but it won't block Suppressed failures will count as a failure, but it won't block
the build, and is appropriate for regressions or bad test the build, and is appropriate for regressions or bad test
failures. failures.
Flakey failures count in a category by themselves and won't block
the build. If any are present then a different exit code will be
produced from the test run so that CI runners can react accordingly.
Additinally, a *description* meta variable can be added to the test to describe Additinally, a *description* meta variable can be added to the test to describe
it's funciton. it's funciton.
meta: meta:
"description" -> { "CFE-2971" } "description" -> { "CFE-2971" }
string => "Test that class expressions can be used to define classes via augments"; string => "Test that class expressions can be used to define classes via augments";
The rule of thumb is: The rule of thumb is:
 End of changes. 4 change blocks. 
1 lines changed or deleted 10 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)