Step definizioni in file esterni in Behat

Behat per impostazione predefinita cerca le definizioni di passaggio nel file denominato FeatureContext (tutti i passaggi in un file).
Avendo molti passaggi, è difficile mantenere un file così grande.

Mi piacerebbe avere un file di definizione per file di funzionalità.

Come posso avere definizioni di passaggi in file esterni?

per esempio

 homepage.feature HomepageContext extends FeatureContext 

Utilizzare l'ereditarietà della class e i contesti separati.

 # /features/contexts/ AbstractContext extends BehatContext {} FeaturenameContext extends AbstractContext {} 

Quindi in /feature/FeatureContext.php import i file di context:

 /** * Initializes context. * Every scenario gets it's own context object. * * @param arrays $parameters context parameters (set up via behat.yml) */ public function __construct(arrays $parameters) { // import all context classs from context directory, except the abstract one $filesToSkip = arrays('AbstractContext.php'); $path = dirname(__FILE__) . '/../contexts/'; $it = new RecursiveDirectoryIterator($path); /** @var $file SplFileInfo */ foreach ($it as $file) { if (!$file->isDir()) { $name = $file->getFilename(); if (!in_arrays($name, $filesToSkip)) { $class = pathinfo($name, PATHINFO_FILENAME); require_once dirname(__FILE__) . '/../context/' . $name; $this->useContext($class, new $class($parameters)); } } } } 

Behat ha più opzioni per suddividere il tuo FeatureContext in più classi. In primo luogo, è ansible utilizzare l'ereditarietà php5 vecchia scuola. Se l'ereditarietà non è ciò che si desidera, Behat support anche i sottocontesti: " Utilizzo di sottocontesti ".

Quindi, se si desidera behat.yml nome alla class in modo diverso rispetto a FeatureContext , è ansible ridefinirlo nella sezione " Configurazione del context " del file di configuration behat.yml .

In questo modo, puoi dividere definizioni e hook comuni in classi separate e usarli anche in altre feature suite con il subcontexting o l'ereditarietà.

Ma la tua domanda chiede anche:

Mi piacerebbe avere un file di definizione per file di funzionalità.

Questa richiesta è totalmente sbagliata. Behat e Scenario BDD si occupa di descrivere il comportmento dell'applicazione in termini commerciali e creare un dictionary di test per i comportmenti descritti. Tenendo presente ciò, non è ansible avere logicamente più dizionari diversi per un set di funzionalità. Scrivendo le definizioni dei passaggi, stai dicendo a Behat cosa significa Given I am on "/news" . E quando vuoi che quel passaggio significhi cose diverse da una caratteristica all'altra – stai sbagliando.

Behat consiste in 2 concetti principali e abbastanza separati:

  1. *.feature file *.feature , scritti in linguaggio Gherkin. Questi file dovrebbero essere auto-descrittivi. Significa che dovrebbero fornire tutte le informazioni per il lettore al fine di capirle. Gherkin non è un nuovo linguaggio di programmazione per i tuoi test funzionali, è solo un markdown per le tue storie di utenti!
  2. FeatureContext.php classi FeatureContext.php, descrivono come Behat dovrebbe testare le tue funzionalità. Definisce un dictionary a livello di applicazione da utilizzare con l'intera suite di applicazioni. Questo è un ponte di programmazione tra le user story e gli effettivi test funzionali.

E non dovresti rovinare tutto. Una singola suite di funzioni dovrebbe avere un dictionary a passi singoli (definizioni). Ma potresti usare un singolo dictionary in più di una suite di funzioni grazie all'ereditarietà e ai sottocontesti. E sì, puoi dividere il dictionary della singola suite in più classi php 😉

Una soluzione è la riusabilità orizzontale con i subContexts. Usa un subContext per each "gruppo di caratteristiche".

 class FeatureContext extends BehatContext { public function __construct(arrays $context_parameters) { $this->useContext('math_context', new MathContext()); $this->useContext('bash_context', new BashContext()); } }