Nel nostro team di sviluppo ci sono solo due membri e abbiamo iniziato a lavorare su un'applicazione web di medie dimensioni (Laravel).
La mia domanda riguarda il testing in particolare TDD, Iniziamo veramente a seguire rigorosamente TDD o inizieremo lo sviluppo senza alcun framework di test e in seguito assumeremo alcuni sviluppatori per testare?
Ma se non seguivamo un modello di prova su come i tester (arriveranno dopo un po 'di tempo) si occuperanno della base di codice esistente.
Se stai avviando un progetto greenfield , ti suggerisco di iniziare i test automatici dall'inizio. Fare tutto TDD potrebbe essere una sfida se la squadra ha poca esperienza con TDD. Impostando ancora un minimo copertura del codice il target di dire il 65% si assicura che il codice sia testabile.
Perché vorresti automatizzare i test:
Vorrei scrivere almeno:
L'aggiunta di test a un sistema non progettato per essere testato automaticamente probabilmente non accadrà mai, poiché è piuttosto difficile e richiede molto tempo. Sarà una situazione frustrante e i tester preferiranno test manuali che ti rallenteranno. Se hai bisogno di un ciclo di commercializzazione rapido o di essere in grado di orientare l'attenzione del prodotto sull'automazione dei test sin dall'inizio. Se non lo fai, probabilmente il tuo prodotto resisterà al cambiamento.
Insegnare agli sviluppatori TDD:
Strict Test Driven Development richiede il test per il prossimo bit di codice da scrivere prima di scrivere il codice testato. In questo modo, il tentativo di utilizzare l'API influenza positivamente lo sviluppo dell'API. Scrivere la documentazione prima dell'implementazione può avere un'influenza simile.
Non puoi chiamarlo TDD se i test sono scritti in seguito.
I test stessi non sono sempre utili per i test a lungo termine, poiché tendono a essere ridondanti, interrompono l'incapsulamento e possono essere difficili da mantenere. È più una tecnica di progettazione, con test automatici come effetto collaterale.
Niels van Reijmersdal ha dato un'ottima risposta link permettimi di aggiungere due centesimi a quella.
TDD o no, meglio avere dei test anche se lo scrivi dopo aver scritto il codice. Basta scrivere subito.
Oltre a testare parte, il test comunica anche l'intento del programmatore: "Come deve comportarsi il programma di codice quando lo faccio ...".
Non hai bisogno di copertura al 100% e non devi seguire il rigido TDD, ma se provi, succederanno due cose: 1. Diventerai sempre migliore a TDD 2. Il tuo codice sarà più semplice da testare nella maggior parte delle parti (questo è un vantaggio automatico di TDD). Più facile non significa facile, soprattutto quando non hai esperienza (vedi punto 1).
Leggi altre domande sui tag tdd unit-testing php laravel