Gentoo Development Guide

src_test

Function src_test
Purpose Run pre-install test scripts
Sandbox Enabled
Privilege user
Called for ebuild

Default src_test

From sys-apps/portage-2.1.2.9

src_test() {
	if emake -j1 check -n &> /dev/null; then
		vecho ">>> Test phase [check]: ${CATEGORY}/${PF}"
		if ! emake -j1 check; then
			hasq test $FEATURES && die "Make check failed. See above for details."
			hasq test $FEATURES || eerror "Make check failed. See above for details."
		fi
	elif emake -j1 test -n &> /dev/null; then
		vecho ">>> Test phase [test]: ${CATEGORY}/${PF}"
		if ! emake -j1 test; then
			hasq test $FEATURES && die "Make test failed. See above for details."
			hasq test $FEATURES || eerror "Make test failed. See above for details."
		fi
	else
		vecho ">>> Test phase [none]: ${CATEGORY}/${PF}"
	fi
}

Sample src_test

src_test() {
    cd "${S}"/src/testdir

    # Test 49 won't work inside a portage environment
    sed -i -e 's~test49.out~~g' Makefile

    # Try to run the non-gui tests only
    make test-nongui \
            || die "At least one test failed"
}

Common src_test Tasks

Often the default src_test is fine. Sometimes it is necessary to remove certain tests from the list if they cannot be used with a portage environment. Reasons for such a failure could include:

  • Needing to use X.
  • Needing to work with files which are disallowed by the sandbox.
  • Requiring user input (src_test must not be interactive).
  • Requiring root privileges.

Usually, removing the relevant test from the Makefile using sed or skipping a particular make target is sufficient.

Note

emake should not be used for src_test — trying to parallelise tests unless the Makefile was specifically designed for this can cause all sorts of strange problems.

Try to ensure that tests work properly for your ebuild. A good test suite is extremely helpful for arch maintainers.

Skipping Tests

Sometimes it is necessary to skip tests entirely. This can be done using a dummy src_test function:

src_test() {
    # Tests don't even remotely work inside portage
    true
}

Another option would be to set RESTRICT="test" in the ebuild.

Note

If upstream provide a test suite which doesn't work, consider talking to them about getting it fixed. A broken test suite is worse than no test suite at all, since we are unable to tell whether a test failure indicates a genuine fault.