Non ho mai scritto molte prove di unità, come posso esercitarmi in più?

L'unico modo per esercitarsi è semplicemente farlo. Sto ancora imparando come scrivere test di unità efficaci da solo. Sfortunatamente, hai bisogno di ore al volante per avere la sensazione vera di ciò che sembra un buon test unitario. L'unica scorciatoia a cui riesco a pensare è di lavorare 16 ore al giorno invece di 8 e imparerai il doppio più velocemente, ma solo fino a quando l'affaticamento non si risolverà.

Poche cose che suggerirei:

• Assicurati di lavorare su un'attività che non sia di importanza temporale. Le pressioni del tempo e la sensazione che devi essere fatto subito, è ciò che in genere fa prendere alle scorciatoie e a) non produrre alcun test, b) produrre molto poco o c) produrre test che sono molto difficili da mantenere perché non si ha avuto il tempo di refactoring.

• Affrontare il compito di scrivere test unitari con gli stessi requisiti per la qualità del codice (se non più rigoroso) come si farebbe con il codice di produzione. Alcune persone pensano che i test unitari non vengano rilasciati, quindi non è così importante seguire le buone pratiche e poi finire con i test che sono molto fragili ed estremamente difficili da mantenere.

• Assegna tempo sufficiente non solo per scrivere il test, ma anche per tutte le classi di supporto che renderanno la tua (e altre persone della tua squadra) più facile. Dalla mia esperienza personale, sembra che le persone tendano a prendere scorciatoie quando scrivono dei test perché determinati compiti sono troppo lunghi per codificarli correttamente e perché impiegano ancora più tempo a codificare il codice in una libreria, finiscono per copiare / incollare il codice tra i progetti di test unitari . Ho avviato una libreria di test di unit test per il nostro gruppo con l'intenzione di accelerare lo sviluppo di test futuri (alcune funzionalità comuni nella libreria: codice semplice per la registrazione / verifica di azioni oggetto fittizio, codice per lavorare con i file per aiutare i test unitari che necessità di alimentare dati esterni, hook standard per ignorare le chiamate win32 ...).

• Prendi l'abitudine di praticare TDD dove scrivi test prima del codice. In un primo momento sembra che i test unitari siano molto onerosi, ma dal momento che devi esercitare il codice di produzione che hai appena scritto, TDD ha più che compensato perché diventa incredibilmente facile verificare la funzionalità del codice di produzione in modo anche quando non considerando tutti i benefici a lungo termine, inizierà immediatamente a rimborsare il tempo impiegato per scrivere i test.

Descrive come imparare a scrivere buoni test unitari. Se vuoi semplicemente "sapere" cos'è un buon test unitario, c'è un numero di libri davvero buoni là fuori. (Vorrei iniziare con The Art of Unit Testing )

Crea una semplice classe e scrivi test di unità per essa. Solo attraverso la pratica sarai in grado di capire come è fatto. Se necessario, trova esempi di test unitari in progetti open source o fai riferimento ad alcuni tutorial online come guida.

Buona fortuna per il colloquio!

La comunità del software è divisa in materia di test unitari.

Ti consiglio di non scrivere test unitari, sono per lo più inutili. Sono scritti perché "è una buona pratica", "team maturi / sviluppatori scrivono test di unità" o altri dogmi del settore.

I test di integrazione o end-to-end sono d'altra parte un segno del team che si preoccupa veramente della qualità.

Ad ogni modo, passiamo ad alcuni punti specifici della tua domanda.

1. Scrittura di test per il codice che accetta i dati dal Web.

Inizia con un caso di test percorso felice. Questo test è lì per mostrare che il codice funziona nel suo scenario di base. Questo è super utile per verificare che le modifiche al codice non interrompano l'app in modo sostanziale.

Se la logica che accetta i dati è complicata, scrivere un felice test di percorso per tutti i rami principali di questa logica.

Nella mia esperienza, questo test si ripaga molto rapidamente, di solito entro poche ore dalla sua stesura. Credimi, questo test continua a dare.

Quindi puoi scrivere un test che dimostra la sicurezza e che l'API restituisce 401/403 quando appropriato.

Dopodiché, scrivi test con i dati che mancano i campi obbligatori. In molti casi è possibile scrivere il codice una sola volta ed eseguirlo con diversi campi mancanti.

2. Dati di prova

Il modo più puro per scrivere test è scriverli in modo da creare tutti i dati necessari per il test e quindi eliminare tutti quei dati dopo il test. In pratica, questo spesso non è possibile e una delle strategie più utilizzate è il flashback / ripristino periodico del db (ad esempio una volta al giorno o ogni volta che si eseguono i test).

I test del database presuppongono spesso che alcuni dati di base siano presenti nel database - questo è OK.

3. Stampa per "debug".

È il 2016 e il debugging è più facile e più facile, ma credo che aggiungere linee ai registri sia ancora la strada da percorrere quando non puoi scorrere il codice.