持续集成，使用Propel将实际测试数据输入数据库的最佳实践

Question

我使用Propel ORM复制了一个表模式，为了进行持续的集成，但是Propel只给了我一个完全充实的模式，它没有给我测试数据(或者根本没有必要的数据)。

如何从带有版本控制的propel-gen推进ORM生态系统的实时/测试数据库中获取数据？

Answer 1

他们说，任何事情中的“最佳实践”根本不存在--它是如此主观，以至于人们应该满足于几种形式的“良好实践”中的一种。我认为下面这些都符合这个标签的条件--最终它对我来说很管用。我已经使用PHPUnit大约一年了，也许从零开始在我的项目上使用了六个月。

下面是我在PHPUnit引导阶段(在phpunit.xml中指定)所做工作的概要：

• 删除并创建myproject_test数据库
• 在生成的SQL的预迁移副本上调用insert-sql Propel命令。
• 调用migrate Propel命令
• 扫描我的测试文件夹以获得用于设置测试的生成类，然后依次运行每个测试

手动插入SQL，然后运行迁移的好处是迁移得到了非常彻底的测试。这特别方便，因为在开发中，我有时会做一个down，修改一个迁移类，然后执行一个up来重新运行它:因此，知道它将按顺序运行是令人欣慰的。目前，我计划永久保存我所有的迁移历史；虽然这会给测试和新构建增加很小的延迟，但升级部署不会受到影响。

由于我的构建依赖于有一个旧的SQL文件，所以我避免使用sql generation命令；如果它是意外发出的，则修改后的SQL文件可以在版本控制中进行轻微的恢复。

目前，我只是在localhost上使用myproject_test的数据库名，以便在任何运行测试的地方，其他数据库都不会受到影响。在构建服务器上，可能需要使用不同的凭据进行连接:考虑在switch()语句中检测机器名称，并相应地选择连接详细信息。

为了让您测试数据，我通常倾向于建议您不要使用来自实时系统的数据导出。通常有太多的数据，比如，您通常希望在每个测试中创建数据片段，这样测试就完全独立了。我认为这是一个好主意，有两个原因：

• 您可以并行化独立的测试。因此，当浏览器测试套件运行5个小时时(!)您可以设置更多的生成服务器，以更快地获得绿色构建。
• 您可能希望在本地运行一个测试套件，或者单独运行一个测试，或者一组匹配某个字符串的测试，如果一个测试依赖于另一个测试，这可能无法工作。

这就是我的建筑商班进来的地方。我在我的bootstrap.php中使用它，并在每个包含测试类的文件夹上调用它：

function runBuilders($buildFolder, $namespace)
{
    // I use ! to mark common builders that need to be run first.
    // Since this confuses autoloader, I load that manually.
    $commonBuilder = $buildFolder . '/!CommonBuild.php';
    if (file_exists($commonBuilder))
    {
        require_once $commonBuilder;
    }

    foreach(glob($buildFolder . '/*Build.php') as $class)
    {
        $matches = array();
        $found = preg_match('#/([!a-zA-Z]+)\.php#', $class, $matches);
        if ($found)
        {
            echo '.';

            // Don't use ! characters when creating the class
            $className = str_replace('!', '', $matches[1]);
            call_user_func($namespace . "\\{$className}::build");
        }
    }
}

在!CommonBuild.php中，我添加了不会被测试修改的只读数据，所以只有一个副本是安全的。

我每个PHPUnit测试类都有一个构建类:对于我拥有的每个*Test.php文件，我都会有一个相应的*Build.php。在每个构建器中，都会调用一个build静态方法，因为我手动为每个需要构建的测试运行一个方法。这里有一个简单的例子：

public static function build()
{
    self::buildWriteVarToFieldSuccessfully();
    self::buildWriteVarToFieldUsingFailedMatch();
    self::buildWriteVarToFieldUsingFoundMatch();
    self::buildFailIfVariableIsAnArray();
}

在将来的某个时候，我可能会使用反射来自动运行这些，就像PHPUnit在测试中所做的那样，但现在还可以。

现在，在我的引导脚本中，我使用测试连接完全初始化Propel，所以可以使用普通Propel语句。因此，我将只创建所需的数据，如下所示：

protected static function buildWriteVarToFieldUsingFoundMatch()
{
    // Save an item in the holding table
    $employer = self::createEmployer();
    $job = new \Job\Model\JobHolding();
    $job->setReference('12345');
    $job->setLocationAlias('Rhubarb patch');
    $job->setEmployerId($employer->getPrimaryKey());
    $job->save();

    $process = self::createProcessingUsingRowMatching($employer);
    $process->createSource('VarToFieldTest_buildWriteVarToFieldUsingFoundMatch');
}

我有一个命名约定，即测试类中的testWriteVarToFieldUsingFoundMatch测试在相应的构建类中获得一个名为buildWriteVarToFieldUsingFoundMatch的生成器。它不是在代码中强制执行的，但是这个命名有助于在给定另一个的情况下很容易地找到一个(我经常使用IDE的拆分屏幕特性同时编辑两者)。

因此，在上面的示例中，我只需要一条雇主记录、一条工作记录、一条流程记录和一条源记录来运行这个特定的测试(而不是一个完整的实时导出)。源记录被赋予了一个与测试名称相关的唯一名称，因此它只会在这个测试中使用(我发现这里必须注意复制和粘贴错误--在测试中使用错误数据是非常容易的！)。

创建这类测试数据非常容易，无论您拥有什么样的数据库：user.name字段、address.line1字段等等通常都可以创建包含唯一标识符的数据，这样当您在测试中修改该数据时，您就知道只有该测试才会使用它，因此它与其他测试是隔离的。

出于简单的原因，我选择运行引导程序中的所有构建程序，而不管运行的是什么测试。因为这只需要额外15秒，在我的例子中，可能不值得做一些更复杂的事情。但是，如果您愿意，可以在每个setUp测试中使用PHPUnit方法，检测当前的测试(如果可能的话)，然后运行适当的构建类。