È pratico scrivere retroattivamente le specifiche che documentano un sistema tramite test di accettazione automatici?

Gli scenari BDD hanno generalmente tre scopi:

• Avere conversazioni sugli scenari consente a tutti di discutere del comportamento del sistema ed esplorare eventuali malintesi o lacune nella conoscenza. Questa è una grande cosa da fare comunque, dal momento che otterrai una migliore comprensione di come funziona il sistema e scopri le ipotesi su come dovrebbe funzionare in confronto a come effettivamente fa >.

• L'acquisizione di conversazioni sugli scenari funge da documentazione per il sistema.

• Automazione degli scenari funge da test di regressione per il sistema e aiuta a ridurre il carico del test manuale.

Se tutto ciò che vuoi è documentare gli scenari, potresti star meglio usando un Wiki.

Tuttavia, se in realtà vuoi produrre scenari di regressione, ad esempio perché stai provando a portare un sistema legacy in uno stato gestibile e eseguirai molti processi di refactoring, l'automazione è un'idea eccellente.

Potresti scoprire di voler automatizzare alcuni degli scenari, catturare le aree che stai rifacendo e documentare le conoscenze che scopri altrove.

Non sono sicuro di quali siano questi strumenti, ma suggerirei di ottenere una serie di requisiti, ad es. "Che cosa dovrebbe fare questo programma?" Una volta ottenuto ciò, scrivere test per tutti i requisiti.

Non scriverei test basati sul codice esistente, perché il codice esistente potrebbe essere errato.

Non è necessario scrivere quasi tanti test come sviluppo, perché non è necessario testare ogni funzione nel codice. Invece, stai testando se il sistema nel suo insieme sta facendo quello che dovrebbe. E credo che sarebbe certamente utile.

Generalmente è considerata una buona pratica scrivere le specifiche prima dello sviluppo, ma a volte non accade in questo modo.

Una delle buone caratteristiche di SpecFlow è che può gestire bene i test non implementati. È possibile scrivere un set completo di specifiche ad un livello elevato e tutti restituiranno non conclusivo piuttosto che pass / fail. Inizialmente i test sono solo documentazione, ma mentre lavori su parti specifiche del codice puoi implementare i passaggi e finire con una serie completa di test automatizzati.

Decidere come organizzerai i test è abbastanza importante. SpecFlow funziona bene per test unitari e test di accettazione, ma i due generalmente non si adattano bene alla stessa struttura del documento.