12月初，我们向illumos推出了一个新的测试框架。在方便添加单元测试的同时，该框架还充当了ZFS测试套件的一个端口的登录区，该测试套件以前在STF（Solaris测试框架）下运行。因为做这个港口代表着一种增量投资，而不仅仅是修复那些被破坏的测试，我们需要确定抛弃STF是值得的。以下是我们决定的一些要点。测试与源一起进行我们从一开始就知道我们希望测试与源代码位于同一个存储库中。这让我们摆脱了花三个小时运行套件，却又回到了一大堆失败的可怕境地，并意识到您在太旧或某些情况下，太新的操作系统位上运行测试！它还允许在操作系统中进行更改的开发人员轻松地更新相关测试。为了实现这一目标，我们需要将STF的构建机制连接到illumos中。STF的一个怪癖是，框架本身负责构建在其下运行的任何测试，实际上，框架甚至通过proto区域创建自己的包。这意味着需要在构建计算机上安装额外的软件，作为构建过程本身的一部分。在这一点上，很明显，创建一个新的框架要比分解旧框架以使其适合illumos构建过程更容易。现在，我们用传统的makefile构建这些测试，它比STF方法构建得更快，同时还为.c文件增加了lint清洁度。安全在测试过程中，需要以不同的权限级别运行测试是很常见的。例如，一个测试可能需要验证"常规"用户不能使用给定的权限修改文件，而另一个测试则需要验证root用户是否能够修改文件。ZFS测试套件有两个解决方案来解决这个难题。第一个解决方案内置于STF中–它是一个名为STF_gosu的setuid根二进制文件，它在调用setuid（0）之后执行参数。另一个解决方案是一个名为sunwstcrunwattr的必需包，它本质上是ppriv（1）的setuid根副本。即使"只"在实验室机器上运行，这显然是一个次优的解决方案。在新框架中，每个测试都可以作为特定的用户运行，并且访问是通过sudoers（4）文件控制的。这提供了在不同特权级别下运行测试的灵活性，同时不为每个本地用户保留根登录名。易于配置STF查找要执行的测试，方法是从当前工作目录开始递归目录结构，并使用测试包随附的"STF_description"文件的内容。这使得在给定目录下执行所有测试变得很容易。从不同的目录中挑选测试显然更尴尬。新的框架提供了一个ini风格的配置文件，用户可以用它指定任意数量的所需测试，并以所需的任何顺序运行它们。这有一个令人愉快的副作用，即允许所有测试都在illumos gate中运行，而任何数量的下游发行版都可以维护特定于相关功能或所需测试运行时的配置文件。对于开发人员来说，这就提供了只运行在bug修复或特性开发过程中对他们很重要的一组测试的能力。那么…现在呢？虽然在最初的推送中移植了大量的测试，但是仍然有一些ZFS测试需要从STF移植过来。这是为illumos和ZFS做出贡献的好方法。还有许多来自STC（Solaris测试集合）的其他测试，这些测试可能提供illumos中目前缺少的有价值的测试覆盖率。看一看，也许那里有些东西会让你大吃一惊，甚至会激发你在另一个领域编写自己的测试。也许您在许多发行版中工作，而不是OI，现在可以找到ZFS。如果您有兴趣使用这些测试，和/或在您的平台上为ZFS编写的贡献测试返回illumos，那么可以将此repo用作一种临时区域，在那里您可以创建一个pull请求，其进入门槛略低于illumos RTI所需的门槛。