Testsuite Details

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:

  • 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.
  • driver: Contains the python source code that forms the testsuite framework.
  • 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.
  • tests: Contains the actual test cases to run.
  • timeout: Contains a Haskell program that kills a running test case after a certain amount of time. Used by the testsuite framework.

Testsuite Implementation details

The testsuite driver is just a set of Python scripts, as are all of the .T files in the testsuite. The driver (driver/ first searches for all the .T files it can find, and then proceeds to execute each one, keeping a track of the number of tests run, and which ones succeeded and failed.

The script takes several options:

--config <file>


--rootdir <dir>


--output-summary <file>


--only <test>


-e <stmt>







   def fn(opts):
      opts.expect = 'fail'









The testsuite and version control branches



test(tc1, ...)
test(tc2, ...)
test(tc3, ...)


test(tc1, ...)
test(tc2, ...)
test(tc3, ...)
test(tc4, ...)
test(tc5, ...)




Currently we have decided to branch the testsuite for ghc releases

Last modified 14 months ago Last modified on Jan 16, 2013 4:13:41 PM