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

Question

我使用propel orm复制了一个表模式，以便进行持续集成，但是propel只能得到一个完全充实的模式，它不能得到测试数据（或者基本的必需数据）。
如何从版本控制的propel-gen推进orm生态系统的实时/测试数据库中获取数据？

Answer 1

他们说“最佳实践”在任何事情上都根本不存在——它太主观了，人们应该满足于几种形式的“良好实践”中的一种。我认为下面的内容符合这个标签的要求——而且最终对我来说效果很好。我已经使用phpunit大约一年了，可能已经有六个月的时间从头开始我的项目了。
下面是我在phpunit引导阶段（在phpunit.xml中指定）所做工作的概要：
删除并创建myproject_test数据库
对生成的sql的预迁移副本调用insert-sql推进命令
调用推进命令
扫描我的测试文件夹中的生成类以设置测试，并依次运行每个测试
手动插入sql然后运行迁移的好处是，迁移可以得到真正彻底的测试。这特别方便，因为在开发过程中，我有时会执行migrate，修改迁移类，然后执行down来重新运行它：因此知道它将按顺序运行是令人放心的。目前，我计划永久保留所有迁移历史记录；虽然这会给测试和新构建增加很小的延迟，但升级部署不会受到影响。
由于我的构建依赖于有一个旧的sql文件，所以我避免使用upgeneration命令；如果意外发出该命令，则可以在版本控制中简单地还原修改后的sql文件。
目前，我只是在sql上使用数据库名myproject_test，这样无论测试在何处运行，其他数据库都不会受到影响。在构建服务器上，可能需要使用不同的凭据进行连接：请考虑在localhost语句中检测计算机名称，并相应地选择连接详细信息。
为了给您测试数据，我通常倾向于建议您不要使用从实时系统导出的数据。其中一个原因是，通常会有太多的数据，而且您通常希望为每个测试创建数据块，这样测试就完全隔离了。我认为这是个好主意，原因有二：
您可以并行化独立的测试。所以，当你的浏览器测试套件需要5个小时运行时（！）您可以设置更多的生成服务器以更快地获得绿色生成。
您可能希望在本地单独运行一个测试套件，或单独运行一个测试，或运行一组与某个字符串匹配的测试，如果一个测试依赖于另一个测试，则这可能不起作用。
这就是我的建设者课程的来源。我在switch()中使用它，并在包含测试类的每个文件夹中调用它：

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");
        }
    }
}

在bootstrap.php中，我添加了只读数据，这些数据不会被测试修改，因此只有一个副本是安全的。
每个phpunit测试类有一个构建类：对于我拥有的每个!CommonBuild.php文件，我都有一个对应的*Test.php。在每个构建器中，都会调用一个静态方法，在该方法中，我为每个需要构建的测试手动运行一个方法。这里有一个简单的例子：

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

在将来的某个时候，我可能会使用反射来自动运行这些程序，就像phpunit对测试所做的那样，但现在还可以。
现在，在我的bootstrap脚本中，我使用测试连接完全初始化了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');
}

我有一个命名约定，测试类中*Build.php的测试在相应的生成类中获得一个名为build的生成器。在代码中并没有这样强制执行，但是这个命名可以很容易地找到一个给定的另一个（我经常会使用ide的拆分屏幕功能同时编辑这两个）。
因此，在上面的示例中，我只需要一个雇主记录、一个工作记录、一个流程记录和一个源记录来运行这个特定的测试（而不是整个实时导出）。源记录被赋予了一个与测试名称相关的唯一名称，因此它将只在该测试中使用（我发现必须注意此处的复制和粘贴错误-在测试中使用错误的数据非常容易！）是的。
创建这种类型的测试数据非常容易，无论您拥有什么类型的数据库：testWriteVarToFieldUsingFoundMatch字段，buildWriteVarToFieldUsingFoundMatch字段等等，通常都可以创建包含唯一标识符的数据库，这样当您在测试中修改此数据时，您就知道只有该测试将使用它，因此它与其他测试隔离开来。
为了简单起见，无论运行什么测试，我都选择在引导中运行所有构建程序。因为这只需要额外的15秒，在我的情况下，可能不值得做更复杂的事情。但是，如果您愿意，可以在每个phpunit测试中使用user.name方法做一些聪明的事情，检测当前测试（如果可能），然后运行适当的构建类。