sviluppo guidato dai test - Chi dovrebbe scrivere i test?

Inizialmente, è dovere dello sviluppatore scrivere il test, ma ho notato che in molti casi / sviluppatori e-mature tali casi non forniscono nemmeno l'80% di copertura.
Che ne dici di avere un addetto al controllo qualità dedicato a scrivere TUTTI i test per un determinato progetto anziché lo sviluppatore?
Ci sono dei contro?

In Test-Driven Development, i test devono essere scritti dallo sviluppatore. Altrimenti qualcuno diverso dallo sviluppatore sta guidando lo sviluppo.

Quindi, non appena assegni il compito di scrivere test a un non sviluppatore, quella persona diventa uno sviluppatore.

La mia esperienza in TDD è che scrivere il codice di prova è spesso difficile o più difficile che scrivere il codice di produzione. Pertanto, se si dispone di risorse in grado di scrivere un buon test unitario / codice di test di integrazione, dovrebbero scrivere il codice di produzione che fa passare quei test.

Il compito del controllo qualità è quello di eseguire tipi di test completamente diversi (ovvero test di usabilità / integrazione). In realtà non devono conoscere le tecnologie utilizzate nel codice.

Se sei preoccupato per la copertura a basso codice, devi disciplinare i tuoi sviluppatori. Ad esempio, interrompere il lavoro su qualsiasi nuova funzionalità, fino a quando la copertura del codice non aumenta. Alcune organizzazioni arrivano al punto di avere un hook pre-commit nel loro repository che non consentirà il check-in del codice scoperto.

Ultimo ma non meno importante, nel TTD "puro", non dovrebbe esserci alcun codice scoperto (poiché si scrivono prima i test). Tuttavia ci sono casi (sebbene le persone ne discutano) in cui è accettabile una copertura di codice inferiore. Alcuni sostengono, ad esempio, che scrivere test per getter / setter di POJO è una perdita di tempo.

questi casi non forniscono nemmeno l'80% di copertura

Potrebbe essere un problema di gestione.

O potrebbe essere irrilevante.

In primo luogo, la differenza tra l'80% e il 100% di copertura è probabilmente un costo elevato per un beneficio molto limitato.

"Copertura" può significare qualsiasi cosa. Linee di codice, percorsi logici, ecc. Immagino che intendi linee di codice (non percorsi logici).

Alcuni percorsi logici sono testati piuttosto bene "tramite ispezione". Il codice è ovvio, non ha istruzioni if, ha una complessità molto, molto bassa e probabilmente non ha bisogno di un test aggiuntivo.

Il 20% in più di test non è sempre il 20% in più di qualità.

Secondo. È un problema di gestione. Se la direzione desidera una copertura del 100%, deve istituire un sistema di premi che premia la copertura del 100% anziché "abbastanza buona da rilasciare" una copertura dell'80%.

L'aggiunta di persone di QA per scrivere più test non sarà di grande aiuto.

L'aggiunta di sviluppatori per scrivere più test è ciò che sarà necessario per ottenere una copertura dei test al 100%.

Il test unitario IMHO non è un processo di controllo qualità. Si tratta più di accelerare lo sviluppo (riducendo il ciclo di feed back per gli sviluppatori). Dovrebbe essere fatto dalla persona che scrive il componente (aka unità) con un focus sull'utilizzo dei componenti (da un altro sviluppatore).

Il test funzionale è un processo di controllo qualità che può e deve essere eseguito da un team di controllo qualità. Questi possono essere eseguiti dallo sviluppatore, ma uno non sviluppatore sarebbe meglio in quanto lo sviluppatore potrebbe non conoscere tutti i modi in cui un utente potrebbe utilizzare l'applicazione.

Entrambi possono essere fatti in modo TDD.

TDD non riguarda solo i test, ma anche il design. Scrivere codice solo per superare i test di solito porta a un codice più piccolo e gestibile. Se deleghi qualsiasi altra persona a scrivere i test, delegherai anche la responsabilità di creare un buon codice.

Si noti inoltre che la copertura non ti dirà sulla qualità del codice e non ti dirà se le regole del dominio sono coperte.

Se hai bisogno di almeno l'80% di copertura, devi fare un paio di cose:

• Fornisci ai tuoi sviluppatori gli strumenti di cui hanno bisogno per determinare quale livello di copertura hanno - e assicurati che si tratti di mele su mele. Esiste più di un modo per misurare la copertura.
• Fornire una ricompensa / incentivo per realizzare tale impresa. I programmatori faranno solo ciò che ritengono ripagherà. Se la copertura del 50% è abbastanza buona da garantire la qualità e svolgere tutto il lavoro, è quello che faranno.

Infine, comprendere che esiste una differenza tra i percorsi di esecuzione previsti e i percorsi di esecuzione involontaria . Nel processo di scrittura del codice test driven, potresti aver dimostrato di aver bisogno di una coppia di istruzioni if ​​indipendenti. Di conseguenza, sono disponibili test per due dei quattro potenziali percorsi di esecuzione disponibili. Aggiungi un'istruzione if più indipendente e hai il potenziale per otto percorsi di esecuzione (ovvero sta salendo esponenzialmente).

Comprendi che TDD non prevede necessariamente ogni potenziale percorso di esecuzione, quindi ci sono un certo numero di test che potrebbero dover essere scritti per essere completi ma non sono scritti perché non era necessario testare quel percorso. In breve, TDD non garantisce la copertura, ma garantisce che ci sia almeno un test per dimostrare la ragione d'eter del codice che esiste.