Блог

Я работал над сеточным пакетом для Symfony. Пакет получает объект Symfony и на его основе отображает gridview.

что-то вроде этого:

 
class IndexController extends AbstractController
{

    public function __construct(GridBuilder $grid, BookGrid $userGrid)
    {
        $this->grid = $grid;
        $this->userGrid = $userGrid;
    }

    /**
     * @Route("/")
     */
    public function index()
    {
        return $this->render('index.html.twig', [
            'grid' => $this->grid->build($this->userGrid),
        ]);
    }

}
  

BookGrid является ли класс расширенным, из BaseGridConfigurator которого он должен реализовать getEntity метод:

 class BookGrid extends BaseGridConfigurator
{

    public function getEntity()
    {
        return Book::class;
    }

}
  

GridBuilder использует EntityRepository (в данном случае BookRepository) для получения метаданных объекта, таких как поля, репозиторий и QueryBuilder .

Если я хочу написать модульный тест для пакета, мне нужен класс сущности, чтобы передать его в GridBuilder. Я думаю, что есть два подхода к решению этой проблемы.

1. Создайте макет объекта и репозитория
2. Создайте реальную сущность и класс репозитория внутри моего тестового каталога

Мой вопрос в том, какой подход правильный? и есть ли какой-либо другой способ протестировать пакет, который зависит от объекта?

Спасибо

Предполагая getEntity , что (который, возможно, следует переименовать в getEntityClass ) используется GridBuilder для получения желаемого репозитория сущностей из entity manager внутренне, не было бы проще BaseGridConfigurator предоставить доступ к репозиторию сущностей напрямую? Например. getEntityRepository(): EntityRepository вместо getEntity(): string . Я могу себе представить, что это значительно уменьшило бы количество насмешек, которые вам пришлось бы делать, если все, что вам нужно, это репозиторий сущностей.

В любом случае, документация Symfony по теме модульного тестирования репозиториев объектов рекомендует не использовать модульное тестирование зависимых от репозитория объектов реализаций в целом.

Но если вам нужно, я бы сосредоточился на дизайне, в котором вашей реализации требуется как можно меньше точек соприкосновения с репозиторием сущностей, чтобы свести к минимуму количество насмешек, требуемых тестом. Но все равно предпочел бы издеваться над заглушкой, несмотря ни на что.