src_test

函数 src_test
目的 运行预安装测试脚本
沙箱 启用
权限 用户
调用于 ebuild

默认 src_test

EAPI 6 中的默认测试阶段等同于以下内容

src_test() {
	if nonfatal emake check -n &> /dev/null; then
		emake check
	elif nonfatal emake test -n &> /dev/null; then
		emake test
	fi
}

示例 src_test

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

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

	# Try to run the non-gui tests only
	# pass -j1 if tests do not support being run in parallel
	emake -j1 test-nongui
}

在软件包中支持测试套件

如果打包的软件配备了测试套件,则有必要运行它。有时软件包需要额外的依赖项才能做到这一点,即仅在运行测试套件时才需要的依赖项。此类仅供测试的依赖项应在 DEPEND 或 BDEPEND 后面指定一个 USE 标志;通常,test USE 标志将用于此目的。有关更多信息,请参阅有关 测试依赖项 的部分。

请注意,test USE 标志仅在存在测试依赖项、测试正在有条件地构建或需要根据是否运行测试来更改行为时才需要(例如,在 SRC_URI 中下载大型文件)。它不适合用于简单地表明测试存在并且预期通过。

通常,默认的 src_test 就足够了。有时需要从列表中删除某些测试,因为它们无法与 Portage 环境一起使用。导致此类失败的原因可能包括

  • 需要使用沙箱不允许的文件。
  • 需要用户输入(src_test 不能是交互式的)。
  • 需要 root 权限。

通常,使用 sedMakefile 中删除相关的测试,或者跳过特定的 make 目标就足够了。

尝试确保测试对你的 ebuild 正常运行。一个好的测试套件对于架构维护者非常有帮助。有时需要完全跳过测试。这可以通过在 ebuild 中设置 RESTRICT="test" 来完成。

需要网络或服务访问的测试

有时,测试套件(以及其他构建时程序)会尝试使用远程或本地网络,或运行在主机上的生产服务器。所有这些都是严格禁止的。开发人员应要么修复这些测试以在隔离的环境中工作,要么完全禁用它们,除非用户明确允许。至少,在启用 FEATURES=network-sandbox 时,测试不能失败。

构建过程中禁止访问互联网的原因如下

  • 构建可能在没有或限制了互联网访问的环境中运行,这不能导致测试(构建)失败;
  • 互联网连接可能不稳定(例如,接收不良),在这种情况下,中断的连接或数据包丢失不能导致测试失败或挂起,并且不应该导致不必要的延迟;
  • 互联网连接可能在有限的数据计划上运行,在这种情况下,额外的网络使用可能会导致用户额外收费或其他不便;
  • 测试使用的远程网络服务可能会暂时或永久不可用,导致意外的测试失败;
  • 访问远程站点始终存在隐私问题,并且可能对安全性构成威胁(例如,通过无意中泄露有关系统的信息)。

修复需要访问互联网的测试通常需要与上游合作,并将测试移植到使用模拟或重播数据等测试技术。因此,开发人员向上传报告问题并跳过需要网络访问的测试。建议明确说明为什么跳过测试,以便其他开发人员可以本地重新启用它们以运行更完整的测试套件。

通常认为,依赖于 IPv4 localhost 可以解析并可用于绑定是可接受的。测试只应该连接到作为测试套件的一部分启动的服务。连接到测试环境之外运行的守护进程是不可接受的。

构建过程中禁止访问本地服务器的原因如下

  • 测试必须可靠地运行,而与在整个构建过程中特定服务器是否运行无关,
  • 使用生产服务运行测试极其危险,因为它可能会无意中暴露这些服务中的错误,导致不稳定、数据丢失,甚至暴露安全漏洞。

修复需要访问本地服务的测试通常通过在测试阶段启动这些服务的额外隔离实例来完成。这些服务必须在 UNIX 套接字或环回接口上运行,才能可靠地防止远程访问。

对于在测试阶段公开的所有网络服务(无论是通过 ebuild 还是测试本身),UNIX 套接字比 IP 套接字更受青睐,因为它们提供了更好的独特命名和访问控制机制。IP 套接字可能会与其他本地服务发生端口冲突,并且可以被可能通过测试利用漏洞的本地系统用户访问。

通过 FEATURES=network-sandbox 提供了针对这些问题的额外保护。但是,这只是一个依赖于特定 Linux 内核命名空间机制的可选 Portage 功能,开发人员不应依赖于它被启用。

需要 X11 的测试

一些软件包包含尝试使用用户 X11 会话并在无法连接到它时失败的测试(或其他构建时应用程序)。这些测试需要修复以独立于在构建软件包时可能正在运行或可能没有运行的 X11 服务器。

如果所讨论的程序并不严格需要 X11,而只是尝试利用 DISPLAY 变量被设置,最好的解决方案是在 ebuild 中取消设置此变量。

src_test() {
	# tests attempt to connect to X11 and fail when it is set
	# however, they work just fine without X11
	unset DISPLAY

	default
}

如果软件包实际上需要一个正在运行的 X11 服务器才能运行完整的测试套件,则可以使用 virtualx eclass 为测试提供一个隔离的 Xvfb 环境。它提供了一个虚拟 X11 显示器,它没有连接到任何物理设备,并且程序可以可靠地使用它。

inherit virtualx

src_test() {
	virtx default
}