Dove si inserisce Behat / Mink nella pipeline CI / CD

1

Quindi ho un progetto che ha i test BDD con Behat / Mink. Gli scenari che ho usato visone, e quindi richiedono che il codice testabile venga distribuito in modo che Mink possa effettivamente testare le pagine.

Mi chiedo in che modo questi test si adatterebbero in una pipeline / flusso di lavoro CI / CD. Attualmente il nostro flusso di lavoro è semplice quanto push, implementazione, test manuale sulla staging, rilascio manuale, test manuale sulla produzione.

Nella mia testa ho in mente il seguente flusso di lavoro per una pipeline regolare:

  1. Spingi al repo
  2. Il post riceve il hook nel servizio CI o nel nostro server CI (Jenkins?)
  3. Il servizio / server CI esegue l'installazione del compositore ed esegue i test
  4. Se passano distribuisce

Non vedo come possa accadere il passaggio 3 prima della distribuzione, dato che il visone ha bisogno di un url per testare le pagine, e il nuovo codice non è ancora sul server poiché non ha superato i test.

Qualcuno può raccomandare una sequenza di eventi che è meglio per behat, dove i test vengono eseguiti prima della distribuzione alla produzione.

    
posta Adam Copley 03.03.2017 - 12:09
fonte

1 risposta

1

I test di WebDriver (come i test di Mink nel tuo caso) sono essenziali per qualsiasi applicazione web che serve un'interfaccia / interfaccia utente interattabile, poiché ti danno fiducia sul comportamento della tua applicazione in risposta alle interazioni dell'utente. Senza di essi, al fine di ottenere la stessa sicurezza sulla funzionalità delle tue applicazioni, dovresti testare la tua applicazione manualmente in un modo eccessivamente lungo.

In generale, si desidera eseguire i test già in locale, prima di spingere la build in CI. È possibile farlo eseguendo il server su localhost ed eseguendo i test sulle pagine servite localmente.

Questo ti permette di rilevare gli errori il prima possibile, mantenendo il ciclo di feedback breve e riduce la frequenza di avere un codice rotto nel repository su cui tu e altri sviluppatori fate affidamento come base per lo sviluppo.

Quindi, eseguili di nuovo sui tuoi ambienti di staging, che ti daranno la certezza che non solo siano in esecuzione sul tuo computer, ma anche su un ambiente che è molto più vicino in termini di configurazione al tuo ambiente di produzione. / p>

Un flusso di lavoro per una pipeline con 2 ambienti (staging e produzione) potrebbe essere simile a questo:

  1. Scrivi un codice veramente accurato: D
  2. Esegui test localmente (compresi i test WebDriver)
  3. Se tutti i test sono verdi, premi su repo
  4. Distribuire nuova build nell'ambiente di gestione temporanea
  5. Esegui test sulla build dell'ambiente di staging (inclusi i test di WebDriver)
  6. Se tutto è verde, distribuisci la nuova build in produzione

Spero che questo aiuti:)

    
risposta data 04.03.2017 - 14:07
fonte

Leggi altre domande sui tag