Ricordo che al TechEd si parlava proprio con Mauro di questo problema. Non sono un fanatico del TDD e lo utilizzo raramente, però sono un accanito sostenitore dei test, senza fare fondamentalismo, talvolta scrivo i test prima, talvolta invece li scrivo dopo, non testo tutto ma cerco di creare una batteria di test che sia in grado di verificare le parti più delicate del codice. In generale mi piace avere un supporto di test quando faccio re factoring.
Talvolta, soprattutto per le strutture MVC in cui ho interfacce complicate, i test iniziano perl a diventare decisamente complessi, con forte uso di test double, e quindi talvolta capita che si fa il test, poi si scrive il codice, si ottiene una barra rossa e quando si va a controllare in dettaglio si scopre che il test è fatto male. Questo solleva una questione decisamente delicata, chi si assicura che i test siano veramente corretti? La morale è che i test vanno tenuti il più semplici possibile, se un test è troppo complesso allora si rischia che.
- Abbia errori il test e non il codice testato
- Sia fragile e quindi va mantenuto troppo spesso
- Sia poco significativo.
- Sia lento
In particolare il terzo punto è interessante, se un test è complesso può fallire per molte ragioni e quindi dal suo fallimento non si capisce che c'è qualche cosa che non va, ma non si sa cosa, per cui forse vale la pena chiedersi se non valga la pena droppare il test stesso. Ricordate infatti che un buon test vi fa capire dove cercare l'errore solamente dal nome o a limite dalla stringa di errore del Nunit.
Keep your tests simple J.
Alk.