From 126131d3b37b4d771cade7ba588efc7f47a8be25 Mon Sep 17 00:00:00 2001 From: Matthias Maier Date: Tue, 12 Aug 2014 23:36:50 +0200 Subject: [PATCH] Testsuite: Small documentation update --- doc/developers/testsuite.html | 93 ++++++++++------------------------- 1 file changed, 25 insertions(+), 68 deletions(-) diff --git a/doc/developers/testsuite.html b/doc/developers/testsuite.html index 3d681ac44a..6a9b02286b 100644 --- a/doc/developers/testsuite.html +++ b/doc/developers/testsuite.html @@ -17,7 +17,7 @@

The deal.II Testsuite

- The deal.II testsuite consists of two parts: + The deal.II testsuite consists of two parts: build tests and the regression testsuite. While the build tests are used to check that the @@ -29,17 +29,16 @@

- deal.II has a testsuite that has, at the time this article is written - (mid-2013), some 2,900 small programs (growing by roughly one per day) - that we run every time we make a change to make sure that no existing - functionality is broken. The expected output for every test is stored in - our subversion archive, and when you run a test you are notified if a - test produces different output. These days, every time we add a - significant piece of functionality, we add at least one new test to the - testsuite, and we also do so if we fix a bug, in both cases to make sure - that future changes do not break what we have just checked in. Machines - running tests send results - back home and these are then converted into + deal.II has a testsuite that currently has (mid-2014), some 3,400 + small programs (growing by roughly one per day) that we run every + time we make a change to make sure that no existing functionality is + broken. The expected output for every test is stored in an output + file, and when you run a test you are notified if a test produces + different output. These days, every time we add a significant piece + of functionality, we add at least one new test to the testsuite, and + we also do so if we fix a bug, in both cases to make sure that future + changes do not break what we have just checked in. Machines running + tests send results back home and these are then converted into a webpage showing the status of our regression tests.

@@ -48,10 +47,6 @@
  1. Quick instructions
  2. Setting up the testsuite
    3. -
      -
    1. Downloading the testsuite
      2. -
    2. Preparing the testsuite
      3. -
  3. Running the testsuite
    1. How to interpret the output
      2. @@ -72,8 +67,8 @@
  4. Submitting test results
  5. Build tests
    6. -
      -
    1. Dedicated build tests
      2. +
        +
      1. Dedicated build tests
    @@ -101,44 +96,16 @@ $ ctest -j16

    Setting up the testsuite

    -

    In order to run it, you need to download and set up the testsuite - first. The following paragraphs detail how to do that. -

    - - -

    Downloading the testsuite

    - -

    - To download the testsuite, check it out from the subversion repository, - along with deal.II. To this end, go to an empty directory where you - want to test deal.II and do this: -

    -$ svn checkout https://svn.dealii.org/trunk .
-
    - (The period at the end puts everything from under trunk/ - into the current directory, rather than creating a - new trunk/ directory.) You will then have - two folders: +

    In order to run it, you need to checkout the git repository with + the development version of deal.II. If you haven't already done this + clone the repository via: 

    -./deal.II
-./tests
+$ git clone https://github.com/dealii/dealii.git
    + More information about the git repository is available on the homepage.

    -

    - Note: CMake will pick up any testsuite that is located in a - tests folder next to the source directory - (../tests). If your test directory is at a different - location you have to hint during configuration by specifying - TEST_DIR: -

    -$ cmake -DTEST_DIR=<...>
-
    -

    - - -

    Preparing the testsuite

    -

    To enable the testsuite, configure and build deal.II in a build directory as normal (installation is not necessary). After that you @@ -728,20 +695,11 @@ $ ctest -V -R "category/my_new_test"

    Checking in

    - Tests are a way to make sure everything keeps working. If they - aren't automated, they are no good. We are therefore very - interested in getting new tests. If you have subversion write access - already, you can add the new test and the expected output - file: -

    -svn add category/my_new_test.cc
-svn add category/my_new_test.output
-svn commit -m "New test"
-
    - If you don't have subversion write access, talk to us in the - discussion group; writing testcases is a worthy and laudable task, - and we would like to encourage it by giving people the opportunity to - contribute! + Tests are a way to make sure everything keeps working. If they aren't + automated, they are no good. We are therefore very interested in + getting new tests. Talk to us in the discussion group! Writing + testcases is a worthy and laudable task, and we would like to + encourage it by giving people the opportunity to contribute!

    @@ -887,8 +845,7 @@ ctest -j4 -S ../cmake/scripts/run_buildtest.cmake

    Note: Build tests require the designated build directory to be - completely empty and the source directory to be under subversion - version control. If you want to specify a build configuration for + completely empty If you want to specify a build configuration for cmake use a configuration file to preseed the cache as explained above: 

    -- 
2.39.5