È abbastanza facile coprire il tuo codice scrivendo i test prima usando TDD e sai quando fermarti una volta che hai implementato una funzione.
Per me è più difficile decidere quanti test funzionali scrivere per dire un servizio REST.
Attualmente mi trovo in una situazione in cui un servizio restituisce pochi campi in JSON e posso creare / aggiornare / recuperare / eliminare una voce. Vi sono casi in cui vengono lanciati errori se ad esempio per uno o più campi è stato assegnato un valore errato. Inoltre ci sono delle dipendenze e dato un valore per un campo renderebbe un altro non valido con un determinato valore. Quindi il servizio sta facendo qualche convalida.
Ho poche opzioni (forse vedi e suggerisci di più):
- Scrivi test funzionali per ciascun caso per verificare che il sistema si comporti come previsto e, naturalmente, scriva insieme i test unitari. E test di integrazione se ne hai bisogno.
- Scrivi alcuni test funzionali per verificare che il formato / il codice di stato / intestazioni di risposta siano validi ma non coprano ogni caso in quanto è possibile coprirli con test di integrazione / unità dire test al limite del servizio insieme al livello di persistenza (repository) senza controller Così potrei perdere la fiducia nel garantire che il mio servizio REST effettui il marshall dei risultati come previsto.
Ovviamente ci sono trade off. Nel primo scenario - maggiore sicurezza, più tempo per scrivere test, impiega più tempo a costruire un artefatto perché ho più test che funzionano più lentamente. Nel secondo scenario - build più veloce, abbastanza alta sicurezza ma non all'altezza dello scenario 1, meno tempo dedicato alla scrittura dei test funzionali.
Qual è la tua esperienza / vista su questo e quale pensi sia la migliore opzione?