Как протестировать контекст Behat?

Question

Behat является очень хорошим инструментом, BDD/TDD/DDD ИМХО основа SOLID кодирования, но ...

Я часто вижу проекты с использованием Behat с довольно сложными классами контекста, которые не тестируются.

Например: Sylius/TaxonomyContext или Sylius/ProductContext

/** 
* @Given /^taxonomy "([^""]*)" has following taxons:$/ 
*/ 
public function taxonomyHasFollowingTaxons($taxonomyName, TableNode $taxonsTable) 
{ 
    $taxonomy = $this->findOneByName('taxonomy', $taxonomyName); 
    $manager = $this->getEntityManager(); 
    $taxons = array(); 
    foreach ($taxonsTable->getRows() as $node) { 
     $taxonList = explode('>', $node[0]); 
     $parent = null; 
     foreach ($taxonList as $taxonName) { 
      $taxonName = trim($taxonName); 
      if (!isset($taxons[$taxonName])) { 
       /* @var $taxon TaxonInterface */ 
       $taxon = $this->getRepository('taxon')->createNew(); 
       $taxon->setName($taxonName); 
       $taxons[$taxonName] = $taxon; 
      } 
      $taxon = $taxons[$taxonName]; 
      if (null !== $parent) { 
       $parent->addChild($taxon); 
      } else { 
       $taxonomy->addTaxon($taxon); 
      } 
      $parent = $taxon; 
     } 
    } 
    $manager->persist($taxonomy); 
    $manager->flush(); 
} 

Этот пример не «ракетостроение», но у него есть довольно много мест, где он не мог работать. Из моего опыта Behat Контексты могут стать довольно сложными.

Должен ли я также «доверять» своим контекстам так, чтобы они работали на 100% правильно? Или есть руководство/учебник, как я могу проверить Behat Contexts?

Что вы будете делать? Как ты делаешь это?

Answer 1

Я бы сказал, это зависит от того, как вы строите свой тестовый пакет.

Поскольку Behat является основой для создания собственного набора тестов, и поскольку это программное обеспечение, которое будет создано, следует рассмотреть лучшие методы разработки программного обеспечения. Один из них - концепция MVC. В Behat Contexts являются «контроллерами» и не должны содержать в себе много логики. В идеале они должны вызывать требуемые методы в базовых услугах, что обеспечит основные функции.

Конечно, для простых готовых шагов (например, с помощью расширений Mink и т. Д.) Довольно легко создать несколько тестов, в то время как для более сложной логики я бы рекомендовал создать службу, которая обрабатывает тяжеловесные логики, проверит и т. д. Таким образом, вы можете протестировать изолированную службу со всех сторон, сохраняя при этом свой «контрольный» контекст достаточно чистым и простым.

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

Для сложных случаев, как в приведенном примере, я попытаюсь инкапсулировать некоторый код в сервис-менеджер и оставить простой контроллер без каких-либо тестов, обеспечивая при этом широкое покрытие для основных служб.