Come può un tecnico di prova aiutare lo sviluppo guidato dai test in continua integrazione?

Naviga le tue risposte
4

In un ambiente in cui non è possibile unire il codice che non supera i test, ovviamente non è possibile unire nuovi test falliti.

Ma come gestire un bug exploit appena scoperto, nel senso che hai scritto un nuovo test che espone un bug già esistente? Lo sviluppo basato sui test direbbe: Hooray, hai il test, ora correggi il bug e poi commetti entrambi.

Ma se tu a) sei un ingegnere di test che ha trovato l'exploit ma non sei in grado di risolverlo o b) potresti ripararlo ma non ora?

Opzione 1: Esegui il test su un ramo aggiuntivo, menzionalo nel problema del bug e in sostanza lascia il codice finché qualcuno non ha pietà e basa la sua correzione su questo ramo e impegna entrambi.

Opzione due: Segna il test in qualche modo come "non è bello che fallisce ma è previsto", uniscilo e l'integrazione continua lo lascia passare. Non appena il bug è stato risolto, si termina il trattamento speciale del test e lo si contrassegna come obbligatorio. Forse, l'elemento della configurazione mostrerebbe anche l'elenco dei guasti previsti, quindi hai un altro tipo di bug tracker.

Ci sono pratiche / standard comuni là fuori? Soprattutto per l'Opzione Due, i framework di test standard come JUnit, Google Test, ... hanno un qualche modo per modellarlo?

    
posta PhilLab 22.08.2018 - 20:50
fonte

2 risposte

5

Non interrompere mai la build. Ma i test che dovrebbero passare in futuro sono completamente validi. Molti test runner comprendono una categoria "xfail", "pending" o "todo" per questo tipo di casi. Se uno di questi test (inaspettatamente) inizia a passare, puoi rimuovere questa categoria. Unendo questi test, puoi assicurarti che continuino a compilare ed eseguire, il che potrebbe essere preferibile rispetto alla memorizzazione separata di questi test.

Esempi:

  • In JUnit è possibile utilizzare le annotazioni per contrassegnare i test in sospeso, anche se potrebbe essere necessaria una libreria separata. Semplicemente ignorando il test potrebbe essere insufficiente perché il test non verrà tentato.
  • Google Test può contrassegnare i test come disabilitati e può eseguire tali test, ma interpreta un errore come un errore piuttosto che in sospeso. Con un numero sufficiente di macro, potresti eseguire il rollover della tua soluzione.
  • Uno stato in sospeso è completamente normale negli strumenti BDD come Cucumber.
  • Pytest ha un eccellente supporto per una categoria xfail.
  • Perl's Test :: More ha blocchi TODO.

Se utilizzare questo approccio dipende molto dal flusso di lavoro del tuo team. I test di Todo sono grandi quando si implementa una specifica o si sta affrontando un arretrato di storie di utenti, specialmente in un contesto BDD in cui il test è la specifica. E i test possono essere utili per problemi molto importanti in cui il test è una documentazione preziosa.

Ma per i test normali, potrebbe essere meglio non impantanare la suite di test con molti fallimenti. Quando scrivi un problema o una segnalazione di bug, considera di includere il codice di test in quel problema piuttosto che unirlo. Scrivere un buon test è già una buona parte del debug e risolvere il problema, quindi idealmente il problema può essere risolto rapidamente.

    
risposta data 22.08.2018 - 23:05
fonte
6

Opzione 1. Solo perché non puoi unire codice non significa che non puoi controllarlo . Devi semplicemente creare un ramo per il tuo test fallito, e poi è pronto quando qualcuno inizia a lavorarci sopra.

Detto questo, non è compito nostro decidere. Questo è qualcosa che la tua squadra deve decidere da sé. Non ci sono proiettili magici che puoi adottare per rendere più semplice questa situazione. Fai ciò che funziona meglio per la tua squadra e il tuo modo di lavorare.

    
risposta data 22.08.2018 - 21:10
fonte

Leggi altre domande sui tag

Come risolvi questa scappatoia del modello di pricing? [chiuso] Possibili conseguenze di hack [chiuso]