From 7098e0e100b7b19ba7a03e64be00e5e4696b75c7 Mon Sep 17 00:00:00 2001
From: Wolfgang Bangerth The deal.II testsuite consists of two parts, the
+
+ The deal.II testsuite consists of two parts, the
build tests and the
regression tests. While the build tests
- just check if the
+ just check if the
library can be compiled on different systems and with different (versions
of) compilers, the regression tests are actually run and their output
compared with previously stored. These two testsuites are
@@ -61,9 +61,9 @@
after some time (results are collected and processed by a program that is
run periodically, but not immediately after a mail has been received).
If your compiler is not in the standard path or has a strange
name (like The deal.II Testsuite
-
- Configuring for a special compiler
-
+
mycc
for C and myCC
for C++),
your template would be something like this (assuming you work with the
@@ -110,7 +110,7 @@
rm -rf deal.II
-
+
The only difference is that one has to give the option
BUILDTEST=yes
to the call to make
. This is so
because for the make file to work it depends on a file that is created by
@@ -213,7 +213,7 @@
as well. The usual way we use the testsuite is to run all tests
like this
(the same applies as above: make -jN
can be used on multicore
- machines):
+ machines):
deal.II/tests> make report | tee report
@@ -252,8 +252,8 @@
grep -v + report
-
If you want to do a little more than just that, you should consider running @@ -335,7 +335,7 @@ As mentioned above, we add a new test every time we add new functionality to the library or fix a bug. If you want to contribute code to the library, you should do this - as well. Here's how: you need a testcase, + as well. Here's how: you need a testcase, a subdirectory with the same name as the test, an entry in the Makefile, and an expected output.
@@ -347,7 +347,7 @@ //---------------------------- my_new_test.cc --------------------------- // $Id$ // -// Copyright (C) 2005 by the deal.II authors +// Copyright (C) 2005 by the deal.II authors // // This file is subject to QPL and may not be distributed // without copyright and license information. Please refer @@ -366,7 +366,7 @@ // all include files you need here -int main () +int main () { std::ofstream logfile("my_new_test/output"); deallog.attach(logfile); @@ -382,7 +382,7 @@ int main ()You open an output file in a directory with the same
name as your test, and then write
- all output you generate to it,
+ all output you generate to it,
through the deallog
stream. The deallog
stream works like any
other std::ostream
except that it does a few more
@@ -397,7 +397,7 @@ int main ()
There are a number of directories where you can put a new test.
Extensive tests of individual classes or groups of classes
have traditionally been into the base/
,
- lac/
, deal.II/
, fe/
,
+ lac/
, deal.II/
, fe/
,
hp/
, or multigrid/
directories, depending on
where the classes that are tested are located.
- In order for the Makefiles to pick up your new test, you have to
- add it there. In all the directories under tests/
- where tests reside, there is a separate Makefile that contains a
- list of the tests to be run in a variable called
- tests_x
. You should add your test to the bottom of
- this list, by adding the base name of your testfile, i.e., without
- the extension .cc
. The entries can contain
- wildcards: for example, in the tests/bits/
directory,
- the tests_x
variable contains the entry
- petsc_*
which at the time of this writing tests 120
- different tests that all match this pattern.
-
- If you have done this, you can try to run + Once you have done this, you can try to run
make my_new_test/output@@ -455,7 +439,7 @@ int main ()
If you run your new test executable, you will get an output file
mytestname/output
that should be used to compare all future
- runs with. If the test
+ runs with. If the test
is relatively simple, it is often a good idea to look at the
output and make sure that the output is actually what you had
expected. However, if you do complex operations, this may
@@ -471,7 +455,7 @@ int main ()
following way: for each test, we have subdirectories
testname/cmp
where we store the expected results in a file
testname/cmp/generic
. If you create a new test, you should
- therefore create this directory, and copy the output of your program,
+ therefore create this directory, and copy the output of your program,
testname/output
to testname/cmp/generic
.
i686-pc-linux-gnu
box and use
gcc4.0
as your compiler, then the following files will be
- sought (in this order):
+ sought (in this order):
-testname/cmp/i686-pc-linux-gnu+gcc4.0 -testname/cmp/i686-pc-linux-gnu+gcc3.4 +testname/cmp/i686-pc-linux-gnu+gcc4.0 +testname/cmp/i686-pc-linux-gnu+gcc3.4 testname/cmp/i686-pc-linux-gnu+gcc3.3 testname/cmp/generic@@ -516,7 +500,7 @@ testname/cmp/generic for your own platform and compiler, and that's alright: someone else will create the output files for other platforms eventually. You only have to copy your output file to -
testname/cmp/generic
.
+ testname/cmp/generic
.
@@ -547,7 +531,7 @@ testname/cmp/generic
Tests are a way to make sure everything keeps working. If they aren't automated, they are no good. We are therefore very @@ -556,7 +540,7 @@ testname/cmp/generic file, and to commit them together with the changed Makefile, like so:
- svn add bits/my_new_test.cc + svn add bits/my_new_test.cc svn add bits/my_new_test svn add bits/my_new_test/cmp svn add bits/my_new_test/cmp/generic @@ -584,7 +568,7 @@ testname/cmp/generic contribute! - + The deal.II mailing list-- 2.39.5