The name of the derivation produced by the tester is `shellcheck-${name}` when `name` is supplied.

`src` (path-like)
: The path to the shell script(s) to check.
  This can be a single file or a directory containing shell files.
  All files in `src` will be checked, so you may want to provide `fileset`-based source instead of a whole directory.

### Return value {#tester-shellcheck-return}

A derivation that runs `shellcheck` on the given script(s), producing an empty output if no issues are found.
The build will fail if `shellcheck` finds any issues.

## `shfmt` {#tester-shfmt}

Run files through `shfmt`, a shell script formatter, failing if any files are reformatted.

:::{.example #ex-shfmt}
# Run `testers.shfmt`

A single script

```nix
testers.shfmt {
  name = "script";
  src = ./script.sh;
}
```

Multiple files

```nix
let
  inherit (lib) fileset;
in
testers.shfmt {
  name = "nixbsd";
  src = fileset.toSource {
    root = ./.;
    fileset = fileset.unions [
      ./lib.sh
      ./nixbsd-activate
    ];
  };
}
```

:::

### Inputs {#tester-shfmt-inputs}

`name` (string)
: The name of the test.
  `name` is required because it massively improves traceability of test failures.
  The name of the derivation produced by the tester is `shfmt-${name}`.

`src` (path-like)
: The path to the shell script(s) to check.
  This can be a single file or a directory containing shell files.
  All files in `src` will be checked, so you may want to provide `fileset`-based source instead of a whole directory.

`indent` (integer, optional)
: The number of spaces to use for indentation.
  Defaults to `2`.
  A value of `0` indents with tabs.

### Return value {#tester-shfmt-return}

A derivation that runs `shfmt` on the given script(s), producing an empty output upon success.
The build will fail if `shfmt` reformats anything.

## `testVersion` {#tester-testVersion}

Checks that the output from running a command contains the specified version string in it as a whole word.

NOTE: This is a check you add to `passthru.tests` which is mainly run by OfBorg, but not in Hydra. If you want a version check failure to block the build altogether, then [`versionCheckHook`](#versioncheckhook) is the tool you're looking for (and recommended for quick builds). The motivation for adding either of these checks would be:

- Catch dynamic linking errors and such and missing environment variables that should be added by wrapping.
- Probable protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.

By default, the command to be run will be inferred from the given `package` attribute:
it will check `meta.mainProgram` first, and fall back to `pname` or `name`.
The default argument to the command is `--version`, and the version to be checked will be inferred from the given `package` attribute as well.

:::{.example #ex-testversion-hello}

# Check a program version using all the default values

This example will run the command `hello --version`, and then check that the version of the `hello` package is in the output of the command.

```nix
{
  passthru.tests.version = testers.testVersion { package = hello; };
}
```

:::

:::{.example #ex-testversion-different-commandversion}

# Check the program version using a specified command and expected version string

This example will run the command `leetcode -V`, and then check that `leetcode 0.4.2` is in the output of the command as a whole word (separated by whitespaces).
This means that an output like "leetcode 0.4.21" would fail the tests, and an output like "You're running leetcode 0.4.2" would pass the tests.

A common usage of the `version` attribute is to specify `version = "v${version}"`.

```nix
{
  version = "0.4.2";

  passthru.tests.version = testers.testVersion {
    package = leetcode-cli;
    command = "leetcode -V";
    version = "leetcode ${version}";
  };
}
```

:::

## `testBuildFailure` {#tester-testBuildFailure}

Make sure that a build does not succeed. This is useful for testing testers.