Sono uno sviluppatore Java, che lavora su un piccolo progetto. Siamo tre persone nel team, abbiamo un budget per 3 mesi di codifica (+ un po 'di tempo per l'analista, il project manager e il team di QA). È un piccolo progetto, il budget è davvero limitato. C'è qualche supporto nella nostra organizzazione per fare i test unitari, ma non ho incontrato nessun esperto in questo settore. Motivato da libri e discussioni, ho iniziato a fare i test unitari. Ho una certa esperienza limitata con framework e approcci, quindi non testo tutti i getter, mi concentro sul codice aziendale, utilizzo il plugin Mockito e MoreUnit Eclipse per generare lo scheletro e Mock. Progetto il mio codice in anticipo, utilizzo un sacco di schemi di progettazione, mantengo pulito il mio codice, con metodi brevi, rispetto la Single Responsibility Principe e ho metodi molto più pubblici che privati. Non è perfetto, ma è il meglio che posso fare dopo 5 anni di esperienza commerciale in un'azienda e in un'azienda di medie dimensioni.
Quindi perché fare test unitari mi prende la stessa quantità di tempo, o anche più alto, di codificare codice produttivo? Dopo gli ultimi due giorni di test unitari ho trovato solo un piccolo bug e non è venuto dai test, l'ho trovato solo casualmente mentre cercavo nel codice di produzione. Dove sono i benefici di cui parlano le persone? Ogni refactoring ha causato solo il lancio di test unitari esistenti e non mi hanno mai detto se avessi influenzato il resto del sistema. Ogni test di classe I ha preso in giro l'ambiente circostante, quindi se cambio una classe, non inciderà sugli altri test e non saprò se ho incasinato il sistema con il mio resto.
Cosa mi manca? Sto sbagliando?
Modifica: per aggiungere alcuni numeri, trascorro circa l'80% del tempo progettando e codificando, e il 20% da test unitari, quindi solo una piccola parte del mio codice è coperta da test. Provo a fare un test unitario di 1,5 mesi, di solito dopo aver terminato alcune funzionalità e testare approssimativamente la mia macchina di sviluppo locale.