Come iniziare l'abitudine di scrivere un test unitario come dipendente? (o dovrei?) [duplicare]

Question

Come iniziare l'abitudine di scrivere un test unitario come dipendente? (o dovrei?) [duplicare]

#1 da (15 voti)
#2 da (3 voti)
#3 da (2 voti)

15

Lavoro in un team che scrive principalmente siti PHP di piccole dimensioni. Attualmente non abbiamo l'abitudine di scrivere un test unitario. I test vengono eseguiti utilizzando il sito come utente dal nostro PM, che non sa come codificare e UAT dal cliente. Tuttavia, dato che i progetti che prendiamo diventano più grandi, inizia ad avere più bug creati a causa del cambio di codice e potrebbe non essere scoperto poiché il test è già stato eseguito su quella parte.

Ad esempio, dopo aver eseguito la parte A & B, il bug si trova nella parte C. Dopo il debug della parte C, causa un bug nella parte A, ma non viene notato poiché il test è stato eseguito su quella parte. Man mano che il progetto si ingrandisce, potrebbe non essere possibile testare l'intero sito dopo ogni modifica. Quindi penso che sia ora di introdurre il test unitario.

Il problema è che il programma è stretto e non ho molto tempo per fare questo lavoro extra, quindi non è possibile scrivere casi di test su ogni caso, per non parlare dell'approccio di sviluppo basato sui test. Inoltre, ho bisogno di dimostrare che scrivere un caso di test non è una perdita di tempo in modo che i miei compagni di squadra inizieranno a scrivere casi di test e, cosa più importante, il mio capo ci concederà più tempo per farlo. Sto pianificando di iniziare a scrivere unit test sulle principali funzioni e se inizia a rilevare bug che in precedenza non sono stati notati, ma non ho idea di quale funzione scegliere. La maggior parte delle guide là fuori ci dice solo di scrivere un test per ogni caso che non è possibile per la nostra situazione. C'è qualche consiglio su quale test unitario iniziare?

testing unit-testing

posta cytsunny 31.10.2016 - 03:30

fonte

3 risposte

Leggi altre domande sui tag testing unit-testing

Differenza tra gestore, responsabile e controllore Avvicinamento di interni Java / JVM [chiuso]

score 15 · Answer 1

Le buone abitudini di codifica iniziano a casa.

Seriamente, finché non ci si abitua, tienilo a casa. Guarda, tutti mettono alla prova il loro codice. Il test delle unità è un modo per automatizzare i test. Se pensi che si tratti di guadagnare più tempo da dedicare ai test, non sei pronto. Sarai pronto quando scrivi i test unitari perché ti fanno risparmiare tempo.

Questo non ha nulla a che fare con il tuo capo. In realtà il tuo capo non ha mai nemmeno bisogno di vedere i tuoi test. Fino a quando il tuo negozio non si sottoporrà ai test unitari, potresti tenerli nel proprio ramo di controllo del codice sorgente locale. Non è necessario mostrarli a nessuno.

Se vuoi rendere popolari i test unitari nel tuo ufficio, il modo per farlo è essere abbastanza bravo da farlo essere il ragazzo il cui codice è più veloce e privo di bug di chiunque altro. Finché non sarai quel tipo, parlare di questo ti renderà solo il ragazzo fastidioso che cerca di rallentarci.

Se sei l'unico a farlo, dovresti essere abbastanza bravo da insegnarlo prima di diffonderlo. Oppure interromperai i lavori mentre altri lo rovinano e lascia il capo a chiedersi da dove sia venuta questa stupida idea di test delle unità.

Test unitari e TDD sono discipline efficaci. Non usarli sulla fede. Quando sarai abbastanza bravo da usarli correttamente non avrai bisogno di un'abitudine. Non avrai bisogno di giustificarli. Li raggiungerai solo perché ti trovi di fronte a qualcosa di difficile e sai che questa è la via più facile.

Finché non sei così bravo, non dare loro una cattiva reputazione provandoli al lavoro troppo presto.

score 3 · Answer 2

Purtroppo non penso che ci sia una risposta facile alla tua domanda. Dovrebbe essere abbastanza facile trovare qualcosa da isolare per il test, ad es. alcuni moduli che hanno poche dipendenze, ma per mostrare i benefici immediati del test è difficile. I benefici di solito mostrano la strada in un prodotto più manutenibile e robusto con meno errori.

Un problema con i test unitari è che anche se mostrano se qualcosa si rompe in un'unità, non necessariamente catturano gli errori che i test di accettazione oi test di integrazione potrebbero catturare e quindi i tuoi sforzi non convinceranno la direzione ad adottare test perché la tua applicazione si interrompe comunque. Ci sono molti modi per sbagliare quando sei appena agli inizi.

Però tocchi su un punto importante. È importante coinvolgere la tua squadra e il tuo management con i test.

Alla fine devi trovare un modo per mostrare alla dirigenza che costa le entrate della società, quindi saranno molto più inclini ad ascoltare. Concordo con coloro che sostengono l'approccio diplomatico e, se ciò non dovesse funzionare, l'azienda potrebbe semplicemente non trovarsi in una fase in cui adotterebbe i test.

A differenza di altri, voglio che tu sia quel ragazzo fastidioso che rallenta le cose. Prima di tutto perché non sono d'accordo sul fatto che stai rallentando le cose volendo migliorare le prestazioni della squadra, ma le conseguenze di farlo da solo sono a mio parere peggiori. Una squadra in cui tutti fanno le cose da sole solo per (forse) mostrare quello che hanno fatto molto dopo, che incubo.

score 2 · Answer 3

Inizi a scrivere dei test unitari discutendo la questione con il tuo manager e chiedendogli di fare dei test delle unità di scrittura una parte del tuo lavoro. E quando lui o lei fa parte del tuo lavoro di test di scrittura, scrivi test unitari. Se non fa parte del tuo lavoro, non lo fai.

Che cosa fa parte del tuo lavoro adesso (se pensi che scrivere test di unità sia utile) andrà dal tuo manager e farà in modo che quella discussione. Qual è la tua responsabilità è convincere il tuo manager. Lui o lei è pagato bene per fare il loro lavoro, ed è il loro lavoro per assicurarsi che tutti usano i migliori metodi per sviluppare software.