Dovrei iniziare con il test dell'unità quando insegno a un nuovo sviluppatore?

Question

Attualmente sto lavorando su un progetto che utilizza tecnologie come Silverlight, WCF, EnterpriseLibrary, Unità, LinqToSql, NUnit, RhinoMocks in Net 3.5

mi sto allenando un nuovo sviluppatore che ha una certa esperienza con VB script e SQL, ma nessuna esposizione a .Net

Quasi il 100% del codebase ha una copertura di test unitaria, ma sembra che ottenere il nuovo sviluppo per iniziare a scrivere test di unità sia troppo, c'è abbastanza materiale in Muovetevi in ​​testa, senza la confusione aggiunta dei test unitari e delle prese in giro.

Gli è stato assegnato il compito di implementare nuove funzionalità per la soluzione che attraversa ogni livello, dall'interfaccia utente al database e, come sempre, c'è una forte domanda da parte dei clienti per ottenere la funzionalità in produzione il prima possibile.

Quale pensi che sarebbe l'approccio migliore per far diventare subito qualcuno?

Answer 1

Con assolutamente nessuna esperienza .NET, direi che gira la testa attorno a TDD nello stesso momento in cui l'apprendimento di .NET è un po 'troppo.

Alcune persone con un sacco di esperienza .NET hanno un tempo abbastanza difficile con TDD - richiede un vero cambiamento nell'approccio fondamentale allo sviluppo. Passare da VB a .NET non è difficile, ma richiede tempo.

davvero si vuole evitare confusione - TDD è un buon modoper sviluppare, ma non è il modo in cui e TDD = sviluppo .NET!. In effetti, è totalmente ortogonale - cercando di insegnare una nuova metodologia e una nuova piattaforma allo stesso tempo? Non riesco a vedere come sia una buona idea.

Answer 2

Sembra che il nuovo sviluppatore stia già attraversando una prova dal fuoco.

Sembra che dovresti lasciarlo andare alla grande e iniziare la sua parte dei servizi, dargli del tempo a lavorarci su e, una volta che si sente a suo agio ... quindi avviarlo su Test unitari.

Answer 3

Considerando che ci sono già molte cose da imparare, ho paura di parlare di TDD e test automatici potrebbero essere un po '"troppo": se il tuo nuovo sviluppatore non sa come svilupparsi, non lo saprà come sviluppare i test - e le prove che scriverà probabilmente non saranno veramente utili.

Nella tua situazione, gli avrei lasciato codificare per un paio di giorni/settimane, testando a mano; e quando comincerà a capire la tua base di codice, passerei un po 'di tempo con lui, per qualche programmazione di coppia: sarebbe una grande occasione per introdurre test automatici e rivedere il suo codice/commento/migliorare allo stesso tempo.

Answer 4

Direi di sì: l'intero punto dei test è quello di concentrarsi in un'area. In realtà aiuta a svuotare la testa e non è che ci vogliano più di 10 minuti per imparare NUnit. Certo, probabilmente per un po 'si troverà a lottare un po' con i concetti, ma un po 'di fatica e un sacco di accoppiamenti dovrebbero superarlo molto più facilmente che lanciargli compiti senza la guida fornita da TDD.

Answer 5

Direi di spegnere il programmatore in supporto. Capire il problema degli utenti e cercare il bug, la ricerca dei guasti e il fixing insegneranno ai nuovi programmatori come viene messa insieme l'applicazione, scrivere test è più sul nuovo sviluppo.

Answer 6

Se nella tua area di prova hai una forte presa in giro, avrà seri problemi per capirlo.Tuttavia, se gli assegnassi compiti più semplici (dove non dovrebbe preoccuparsi di Mockery) e impari a scoprire "cosa dovrebbe fare il mio codice?" questo dovrebbe essere fattibile.

Answer 7

Per uno sviluppatore inesperto, il test dell'unità sembra raddoppiare tutto il codice. È un enorme turno.

È davvero necessario lasciarli fallire prima che possano veramente apprezzare i vantaggi dei test unitari.

Answer 8

Se fossi in me, mi piacerebbe unirmi a lui e al TDD. Scrivi un test, scrive il codice che lo fa funzionare, poi scrive il prossimo test e scrivi il codice per farlo funzionare, ecc.

Divertimento, ti fa sperimentare velocemente, fa risparmiare tempo e denaro.

Answer 9

Vorrei iniziare in modo semplice: ritagliare il compito in parti logiche, quindi associarlo con lui fino a quando non riesce a comprendere la parte corrente. Non credo che un'immersione totale nel TDD sarebbe efficace fino a quando non si raggiungerà un buon livello di comfort da parte sua, ma ciò non significa che non si possa esporlo ai test unitari e simili.

Forse, come parte del lavoro di preparazione, è possibile scrivere alcuni test che saranno necessari per eseguire l'attività assegnata. Mentre sta affrontando il problema, potresti guidarlo verso una soluzione generale, usando i test ("luce rossa CATTIVO!") Per dimostrare dove il suo pensiero è spento.

Da lì, puoi "guidare" mentre "naviga" - definisce la funzionalità desiderata per te e puoi chiedergli come testare tale funzionalità. Inizia a scrivere i test con lui in modo che possa vedere la connessione tra i test e il prodotto, quindi lasciarlo lentamente prendere il sopravvento.

Speriamo che, se è in forma, sarà in grado di cogliere i concetti da zero, quindi dedurre come scrivere i propri test (con la tua guida, ovviamente!). L'ultimo passo credo sarebbe quello di gettarlo in piscina e costringerlo a scrivere i test come parte della definizione della funzionalità che vuole scrivere.

Probabilmente non sarà un processo rapido, ma spero che questo gli darà una buona base di test TDD/unità

Answer 10

E 'stato assegnato ai compiti da implementare nuove funzionalità per la soluzione che tagliare tutti i livelli, dall'interfaccia utente al database e, come sempre, c'è una forte domanda da parte dei clienti di per ottenere la funzione in produzione non appena possibile.

Quale pensi che l'approccio migliore sarebbe per ottenere qualcuno fino a velocità?

Se Withold informazioni allora può mai arrivare fino a velocità. Insegnagli come tu farebbe il lavoro.

Come il giovane membro della squadra, (vale a dire i problemi con il programma) "La forte domanda dei clienti" non è suo problema: questo è qualcosa che il team leader e/o responsabile del progetto lo dovrebbe mettere al riparo dal.

Potrebbe essere necessario istruire il cliente: portare un nuovo membro del team che non ha precedenti esperienze con le tecnologie è un investimento che vale la pena a lungo termine.

A breve termine, il cliente (o il cliente) potrebbe vedere poco o nessun vantaggio immediato: perché è lento (apprendimento) e sta prendendo un po 'del suo tempo (non indipendente).

IMO si dovrebbe:

• Non fargli fretta (invece lasciarlo imparare a farlo ben prima che ci si aspetta che lo faccia in fretta)

• Concentratevi su ciò che è necessario per assicurare che il suo l'output non degrada la qualità complessiva dei deliverable del progetto (cioè dovresti sicuramente insegnargli e assicurarti che il suo programma lo permetta, qualunque sia il test degli sviluppatori e i metodi di assicurazione della qualità che ti aspetti dagli sviluppatori)

Detto questo, I don't think that unit test are always necessary. Ma in una situazione in cui è un programmatore nuovo (inesperto), e in cui, ovviamente, si era già deciso che la copertura del test al 100% era la cosa giusta per il progetto questo, trovo difficile capire perché stai pensando cambiare il tuo processo di sviluppo ora per lui (a meno che forse queste caratteristiche che gli sono state assegnate abbiano dei requisiti di pianificazione/qualità che sono diversi dalle altre caratteristiche).

Answer 11

Se non ora, quando? Penso che la linea di ragionamento che sto vedendo in questa discussione sia una scusa per non fare test unitari. Ci sarà sempre un programmatore migliore di me, sarò sempre un programmatore migliore domani.

Anche suggerire che "solo gli sviluppatori di uber ninja" dovrebbero fare test di unità è il messaggio sbagliato da inviare, soprattutto se si valutano le statistiche di copertura al 100%.

Il test delle unità insegna una delle API del codice sotto test in avanti e all'indietro senza che uno sviluppatore apprenda tramite apportare modifiche non testate pericolose al codice di produzione.

Per quanto riguarda il problema di complessità, il codice complesso è un codice complesso. Lo sviluppo da cowboy senza test unitari non lo rende più semplice.

Answer 12

chiedere a qualcun altro di scrivere i test dell'unità e fargli scrivere il codice per eseguire il test. Una volta che si sentirà a suo agio, potrai presentarlo alla creazione di test.

Answer 13

Quello che vorrei fare è dire:

"Usiamo TDD qui, che si farà così, ma prima voglio che mettersi a proprio agio con l'ambiente .NET Poi, in un paio di settimane abbiamo'. Ti siedi e codifica un paio di test unitari insieme. "

Penso che questo gli dia tempo per digerire.