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

我使用Propel ORM复制表模式,以便进行持续集成,但Propel只让我得到一个完全充实的模式,它不会让我获得测试数据(或者根本不需要基本的必要数据).

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

他们说任何事物中的"最佳实践"都不存在 - 它是如此主观,以至于人们应该选择几种形式的"良好实践".我认为下面的标签符合该标签 - 最终它对我有用.我一直在使用PHPUnit大约一年,也许我的项目从头开始使用六个月.

这是我在PHPUnit引导阶段(指定phpunit.xml)中所做的事情的概要:

删除并创建myproject_test数据库

insert-sql在生成的SQL的迁移前副本上调用Propel命令

调用migratePropel命令

扫描我的测试文件夹以获取构建类以设置测试,并依次运行每个测试

手动插入SQL然后运行迁移的好处是迁移得到了彻底的测试.这是特别方便的,因为在开发中我有时会做一个down,修改一个迁移类,然后up重新运行它:因此可以放心地知道它将按顺序运行.目前我计划永久保留我的所有移民历史; 虽然它会给测试和新版本增加非常小的延迟,但升级部署不会受到影响.

由于我的构建依赖于具有旧的SQL文件,因此我避免使用sqlgeneration命令; 如果意外发出,修改后的SQL文件可以在版本控制中轻松恢复.

目前,我只是使用myproject_teston 的数据库名称localhost,因此无论运行哪个测试,其他数据库都不会受到影响.在构建服务器上,您可能需要使用不同的凭据进行连接:请考虑在switch()语句中检测计算机名称,并相应地选择连接详细信息.

为了给您测试数据,我通常倾向于建议您不要使用实时系统中的数据导出.通常情况下,它通常太多,而且您通常也希望每次测试创建数据片段,以便测试完全隔离.我认为这是一个好主意有两个原因:

您可以并行化独立的测试.因此,当您的浏览器测试套件运行需要五个小时(!)时,您可以设置更多构建服务器以更快地获得绿色构建.

您可能希望本地运行测试套件,或者单独进行测试,或者匹配某个字符串的一组测试,如果一个测试依赖于另一个测试,这可能不起作用.

这是我的构建器类的用武之地.我在我的中使用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();
}

在未来的某个时候,我可能会使用Reflection来自动运行这些,就像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测试中的方法做一些聪明的事情,检测当前测试(如果可能),然后运行相应的构建类.