Changes between Version 3 and Version 4 of Building/RunningTests/Adding
- Jul 8, 2011 10:57:10 PM (5 years ago)
v3 v4 1 1 = Adding new test cases = 2 3 This section gives an overview of how to add new test cases to the testsuite. First we give an overview of how the testsuite is designed. 4 5 == Testsuite Design Overview == 6 7 The testsuite is designed largely as follows, where we take the root of the testsuite to be `testsuite/`. Firstly we have the individual test cases to run. Each test case though can be run in multiple ways. These different ways (which are simply called ```ways```) correspond to things like different optimisation levels, using the threaded RTS or not... ect. Some test cases can be run in any way while others are specific to certain ways. The general layout of the testsuite is this: 8 9 * `config`: Contains the definition of the different ways supported. The only file of relevance here is `ghc`. No other Haskell compiler is actually supported by the testsuite. 10 * `driver`: Contains the python source code that forms the testsuite framework. 11 * `mk`: Contains the make source code that forms the testsuite framework. The make part is mostly concerned with invoking the python component, which does the actual work. 12 * `tests`: Contains the actual test cases to run. 13 * `timeout`: Contains a Haskell program that kills a running test case after a certain amount of time. Used by the testsuite framework. 14 15 == Adding a test case == 16 2 17 3 For adding any test case, follow these guide lines and then refer to the more specific examples below for a single module test case and a multiple module test case. All test cases should reside under the `testsuite/tests/ghc-regress/' directory. From now on we assume that directory as our root. … … 85 71 Below we will look at some of the more common test case setups. 86 72 87 == = A single module test case === 73 ==== 88 74 89 75 A single module test case is very easy. Simply name the Haskell source files the same as your test … … 107 93 For more detailed control of a test case, see below. \REF 108 94 109 == = A multiple module test case === 95 ==== 110 96 111 97 A multiple module test case is slightly more complex then a single module one. Firstly we a concerned with how to handle the simplest form of a multiple module test case, that is one where the whole test case can be built in one go using the `--make` command of GHC. If you have more complex needs (like compiling source files that `--make` can't handle, and/or need to compile different modules with different GHC arguments, then see below \REF) … … 135 121 }}} 136 122 137 == = Advanced multiple module test cases === 123 ==== 138 124 139 125 If you have a test case that can't be built with the simpler two methods described above then you should try one of the methods described below. The build method below allows you to explicitly provide a list of source files that GHC should try to build. They are also built in the order you specify. This is useful for test cases say that use a .cmm source file or .c source file, these are files that GHC can build but aren't picked up by `--make`.