我应该对扩展 Sonata Base EntityManager 类的类进行单元测试吗？

Question

这是扩展 BaseEntityManager 的部分代码：

namespace Vop\PolicyBundle\Entity;

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Persistence\ObjectRepository;
use Sonata\CoreBundle\Model\BaseEntityManager;

class AdditionalInsuredTypeManager extends BaseEntityManager
{
    /**
     * @param int $productId
     *
     * @return ArrayCollection
     */
    public function getProductInsuredTypes($productId = null)
    {
        $repository = $this->getRepository();

        $allActiveTypes = $repository->findAllActive();

        // other code
    }

    /**
     * @return AdditionalInsuredTypeRepository|ObjectRepository
     */
    protected function getRepository()
    {
        return parent::getRepository();
    }
}

在这里我正在尝试编写一个单元测试：

public function testGetProductInsuredTypes()
    {
        $managerRegistry = $this->getMockBuilder(\Doctrine\Common\Persistence\ManagerRegistry::class)
            ->getMock();

        $additionalInsuredTypeManager = new AdditionalInsuredTypeManager(
            AdditionalInsuredTypeManager::class,
            $managerRegistry
        );

        $additionalInsuredTypeManager->getProductInsuredTypes(null);
    }

有什么问题：

• 我在嘲笑 ManagerRegistry，但我知道我不应该嘲笑我不拥有的东西。但这是构造函数的必需参数。
• 我收到错误：

找不到 Vop\PolicyBundle\Entity\AdditionalInsuredTypeManager 类的映射信息。请检查“auto_mapping”选项 (http://symfony.com/doc/current/reference/configuration/doctrine.html#configuration-overview) 或将捆绑包添加到原则配置中的“映射”部分。 /home/darius/PhpstormProjects/vop/vendor/sonata-project/core-bundle/Model/BaseManager.php:54 /home/darius/PhpstormProjects/vop/vendor/sonata-project/core-bundle/Model/BaseManager.php:153 /home/darius/PhpstormProjects/vop/src/Vop/PolicyBundle/Entity/AdditionalInsuredTypeManager.php:46 /home/darius/PhpstormProjects/vop/src/Vop/PolicyBundle/Entity/AdditionalInsuredTypeManager.php:21 /home/darius/PhpstormProjects/vop/src/Vop/PolicyBundle/Tests/Unit/Entity/AdditionalInsuredTypeManagerTest.php:22

我不知道如何修复这个错误，但这确实与我假设的扩展 BaseEntityManager 相关。

我看到错误是由这一行引起的：

$repository = $this->getRepository();

我什至不能从构造函数中注入存储库，因为父构造函数没有这样的参数。

关于测试的信息很少：

https://sonata-project.org/bundles/core/master/doc/reference/testing.html

Answer 1

我不能告诉你测试你的存储库是否有用，我也不能告诉你你的错误，除了你很可能不应该扩展学说的实体管理器。如果有任何东西使用自定义 EntityRepository 或编写一个注入 EntityManager（或更好的 EntityRegistry）的服务：

class MyEntityManager
{
    private $entityManager;

    public function __construct(EntityManager $entityManager)
    {
        $this->entityManager = $entityManager;
    }

    public function getProductInsuredTypes($productId = null)
    {
        $repository = $this->entityManager->getRepository(Product::class);

        $allActiveTypes = $repository->findAllActive();

        // other code
    }
}

我可以给你解释一下我是如何处理测试存储库的：

我认为单元测试，尤其是模拟测试，似乎有点浪费。它们只会将您与当前的实现联系起来，因为任何相关的东西都被模拟出来了，所以您很可能不会测试任何行为。

可能有用的是在提供真实数据库连接的情况下进行功能测试，然后对存储库执行查询以查看它是否真的返回预期结果。我通常会为更复杂的查询或使用高级学说功能（如使用自定义ResultsetMap 的本机查询）执行此操作。在这种情况下，您不会模拟 EntityManager，而是使用 Doctrine 的 TestHelper 创建内存中的 sqlite 数据库。这可能看起来像这样：

protected $entityManager;

protected function setUp()
{
    parent::setUp();

    $config = DoctrineTestHelper::createTestConfiguration();
    $config->setNamingStrategy(new UnderscoreNamingStrategy());
    $config->setRepositoryFactory(new RepositoryFactory());

    $this->entityManager = DoctrineTestHelper::createTestEntityManager($config);
}

缺点是，您必须手动注册自定义类型和侦听器，这意味着行为可能与您的生产配置不同。此外，您的任务仍然是设置架构并为您的测试提供固定装置。您也很可能不会在生产中使用 SQLite，所以这是另一个偏差。好处是您不必在运行之间清理数据库，并且可以轻松地并行运行测试，而且它通常比设置完整的测试数据库更快、更容易。

最后一个选项有点接近前一个选项。您可以拥有一个测试数据库，您可以在参数、环境变量或config_test.yml 中定义它，然后您可以引导内核并从您的 DI 容器中获取实体管理器。 Symfony 的 WebTestCase 可以作为这种方法的参考。

缺点是，您必须启动内核并确保为开发、生产和测试设置单独的数据库，以确保您的测试数据不会弄乱任何东西。您还必须设置架构和固定装置，此外，您很容易遇到测试未隔离并开始变得脆弱的问题，例如当以不同的顺序运行或仅运行部分测试套件时。显然，由于这是通过您的引导应用程序进行的完整集成测试，因此与单元测试或较小的功能测试相比，性能占用明显更高，并且应用程序缓存可能会让您更加头疼。

根据经验：

• 我在执行最基本的查询时信任 Doctrine，因此不会测试存储库的简单查找方法。
• 当我编写关键查询时，我更喜欢在更高层间接测试它们，例如确保在验收测试中页面显示信息。
• 当我遇到存储库问题或需要在较低层进行测试时，我会先进行功能测试，然后再进行存储库集成测试。

tl;博士

• 存储库的单元测试大多毫无意义（在我看来）
• 如果您需要，功能测试非常适合以合理的工作量单独测试简单查询。
• 集成测试可确保最类似于生产的行为，但设置和维护起来更加痛苦