Fields

• inputDir :: FilePath

  The original directory in which the sample files can be found. This is provided for backward-compatibility, but the use of the inputDirs alternative is recommended.

• inputDirs :: [FilePath]

  The directories in which the sample files that drive the testing exist. When specified as a relative filepath (suggested) then a directory is relative to the cabal file.

• rootName :: GlobPattern

  The name of the "root" file for each test scenario. The contents of this file are opaque to 'tasty-sweet' and are interpreted by the tests themselves. Each "root" file is the kernel for a set of test cases.

  The root file should not be specified with any path element, it should exist in one of the inputDirs location and it can be specified as a glob pattern.

  The corresponding expected results files will be identified by finding files which match a portion of this name with a "{separator}{expectedSuffix}" appended to it.

• expectedSuffix :: FileSuffix

  The expected suffix for a target pattern for running a test. There may be multiple files specifying expected results for a test (see the validParams below), but a particular test case is comprised of a source file along with a corresponding "expected result" file that is the name of the source file with the expectedSuffix suffix. The suffix should not contain any glob match characters. Note that the suffix is the text that comes after one of the separators below.

  The expectedSuffix *may* start with one of the characters in separators. If this occurs, then the suffix will only be considered if preceeded by that specific separator; otherwise any of the separators may be used prior to the expectedSuffix.

• separators :: Separators

  The separators specify the characters which separate the expected suffix from the rootName, and which also separate the various parameters (if any, see validParams below). Any one of the separators in this list can be used, and a file can used a mixture of the separators in the filename.

  It is also valid to specify no separators, in which case the rootName and expectedSuffix are directly concatenated. This is not a typical usage, however.

  The default separators (returned by mkCUBE) are ".-" meaning that extensions (and parameters) can be separated from the base name by either a period or a dash.

• associatedNames :: [(String, FileSuffix)]

  The associatedNames specifies other files that are associated with a particular test configuration. These files are optional and not all of them appear, but different suffixes may be associated here with a general name. When a test is being generated, any associatedNames that were found will be passed to the test generator for use as supplemental data.

  Specified as a list of tuples, where each tuple is the (arbitrary) name of the associated file type, and the file type suffix (with no period or other separator).

• validParams :: [ParameterPattern]

  The validParams can be used to specify various parameters that may be present in the filename.

  For example, tests might be parameterized by which C compiler ("gcc" or "clang") was used, which target architecture ("x86_64" or "ppc" or "arm"), and which optimization level. The values for these parameters appear in any order in the filenames of any file (other than the rootName) delineated by any of the separators. Not all parameter values are required to appear.

  The following are valid examples:

  foo-gcc-ppc-O3.o
  foo-clang.x86_64.o
  foo.O0-clang.o

  The sugar matching code will attempt to identify the various parameter values appearing in the _EXPECTED_ filename which correspond to the same values in the _ROOT_ filename and provide that information to the test generation process to allow the generated test to be customized to the available set of parameters.

  The associatedNames provided to the test generator will be constrained to those associated names that match the parameter values explicit in the expected name, and called for each combination of unspecified parameter values present in associated names.

  There may actually be multiple sets of parameterized files for each rootName file: the test generator will be called for each set of parameters.

  Each entry in the validParams specifies the name of the parameter and the set of values; one (and only one) parameter may have existential values rather than pre-determined values, as indicated by a Nothing for the parameter value set. Valid parameter values are *not* matched with file globbing (they must be explicit and precise matches) and they cannot be blank (the lack of a parameter is handled automatically rather than an explicit blank value).

Fields

• candidateDir :: FilePath
   
• candidateSubdirs :: [FilePath]
   
• candidateFile :: FilePath
   

Fields

• rootBaseName :: String

  The base of the root path for matching to expected. This has no path elements, no extensions and no parameters. It can be useful to use to compare to other fields in the expected Expectation list of this structure. Note that if the root file matched had parameters as part of the filename, those are not present in this rootBaseName.

• rootMatchName :: String

  Matched root. This is the name of the matched file, (no path elements) that matched the rootName in the input CUBE. This includes any extension or parameter substitutions. This is often the best name to use for displaying this matched item.

• rootFile :: FilePath

  The full actual filepath of the matched root, with all path elements, extensions, parameters, and suffixes present. This is most useful to open or otherwise access the file.

• cubeParams :: [ParameterPattern]

  parameters for match

• expected :: [Expectation]

  all expected files and associated

Fields

• expectedFile :: FilePath

  file containing Expected results

• expParamsMatch :: [NamedParamMatch]

  set of CUBE parameters matched and the matched values.

• associated :: [Association]

  Associated files found