This is a completely rewritten version of what I proposed some time ago (14th 
Nov. 2014). TLDR summary at first:

  - Allows to separate preparation of the environment (full fs, damaged fs, 
...) from a test itself. So multiple tests can be run in exactly the same 
conditions.
  - And a single test can be run in multiple environments.
  - It do not affects existing tests.
  - (I hope I addressed all the formal notes I got last time for my first big 
patch set. :-)

Long version:

The goal of this patch set is to allow a single test to be run in different 
sitations, for example on empty filesystem, full fs, or damaged fs. It provides 
an interface for scripts that can prepare the requested environment and takes 
care of starting the test for each one.

The changes in existing infrastructure are small. Most of the code is a new 
functionality which has to be invoked by a user or a test.

How it works: Most of the it is done in the test itself: The test sets 
"$ENV_NAME" variable and calls "_environment_require $TEST_DIR". Where and when 
the test do this is in hands of its author. When using the ./new script for 
creating a skeleton, everything is prepared, so the author only lists desired 
environments.

The test skeleton already contains code for for iterating over the environments 
and running each of them. Of course, if only one environment is given, then the 
test will run only once as before.

Changes in ./check script are for allowing the user to somehow limit which 
environments are used through two new options: -ex and -eo, for exclude/include 
some environments. However, this only affects the tests that comply with it. So 
it won't selects what tests to run or not. It only exports the limited list to 
the test, which is then free to do whatever it want. (The autogenerated 
skeleton is modified w.r.t. this.)

So already existing tests are not affected by this new functionality at all. 
Also, this gives the author of a test the control over when and how the 
environments should be called. But if he does not wish to be bothered with it 
at all, he can ignore it. The change from what was before is small, only few 
more lines around "put your code here".

Unlike in my previous patch set, I decided to not implement some persistency 
between different tests using the same environment, because with the current 
code, it is possible to achieve it in the tests itself:

Things like a simple check for the content of $TEST_DIR/last_env (and 
eventually writing into it) do the work exactly how it is needed in the 
specific test.

To show how it works, I modified two performance tests (an important motivation 
for these patches) to work with the new environment functionality.


I hope this version is in better shape. :-)

Cheers,
Jan





Jan Ťulák (6):
  new: environments - add support for environments into the check script
  new: environments - new functions in common/rc for environment support
  new: environments - add option for skipping output diff from a test
  new: environments - add performance tests (as example of usage)
  new: environments - create the environment directory
  new: environments - added to the skeleton in ./new script and README

 README                     |  12 ++++-
 check                      | 127 ++++++++++++++++++++++++++++++++++++++++---
 common/rc                  | 130 +++++++++++++++++++++++++++++++++++++++++++++
 environments/empty-files   |  96 +++++++++++++++++++++++++++++++++
 new                        |  34 +++++++++++-
 tests/performance/001      | 111 ++++++++++++++++++++++++++++++++++++++
 tests/performance/002      | 121 +++++++++++++++++++++++++++++++++++++++++
 tests/performance/Makefile |  21 ++++++++
 tests/performance/group    |   7 +++
 9 files changed, 650 insertions(+), 9 deletions(-)
 create mode 100644 environments/empty-files
 create mode 100755 tests/performance/001
 create mode 100755 tests/performance/002
 create mode 100644 tests/performance/Makefile
 create mode 100644 tests/performance/group

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to