Come posso ridurre il tempo necessario per completare il test di regressione un'applicazione pronta per il rilascio?

Ovviamente se testate tutto manualmente, ci vorrà molto tempo. Soprattutto nei progetti di mischia, dove i test sono frequenti e le costanti di tempo sono brevi, è importante utilizzare test automatici.

Una buona soluzione di test è una combinazione di test unitari (che testano una piccola parte del codice, tipicamente una classe) e test di integrazione automatici (che seguono processi end-to-end e casi d'uso nell'applicazione). Alcuni test di integrazione possono essere sicuramente test dell'interfaccia utente e esistono framework per test dell'interfaccia utente che è possibile utilizzare.

È possibile passare gradualmente dai test manuali a quelli automatizzati. Inizia facendo rispettare una pratica che ogni nuovo codice scritto dal team deve avere un test unitario. Leggi su Test-Driven Development, è un approccio un po 'duro ma è un buon punto da cui partire quando si progettano le proprie best practice.

NUnit, combinato con RhinoMocks, è una soluzione eccellente sia per i test unitari che per i test di integrazione.

Dato che si utilizza VS 2010 - il framework MS Test è un framework di test alternativo che è possibile utilizzare. - Vedi qui per un confronto tra NUnit e MS Test link

Ecco un articolo che parla in modo specifico di come scrivere i test dell'interfaccia utente per le applicazioni WPF: link

In generale, quando si gestiscono applicazioni complesse di grandi dimensioni, i test unitari sono di solito il modo migliore per avere una copertura completa, ma anche i più costosi in termini di tempo per scrivere quando si inizia da zero. Probabilmente dovrai refactoring una gran parte del codice che non è stato scritto pensando alla capacità di test. In questi casi è spesso più veloce ed efficiente investire prima nei test di integrazione e di interfaccia utente; utilizzando la fiducia di qualità che forniscono al codice del fattore di ri-fattore per rendere più facile il test dell'unità.

L'approccio più efficiente, che ho usato su più applicazioni ora è il seguente:

• Automatizza i test di integrazione di sistema / end-to-end che richiedono più tempo
• Avvia l'automazione man mano che procedi: i nuovi difetti devono disporre di test automatici per la regressione; se stai modificando un codice che non ha un test intorno, scrivi alcuni
• Non puoi automatizzare tutto: quindi esegui un'analisi costi benefici su quali casi di test desideri automatizzare e su quelli che puoi ancora eseguire manualmente.
• Quando inizi ad automatizzare i test, considera l'integrazione dei test con un motore di Continuous Integration come Teamcity, Bamboo o Cucumber, in modo che i test vengano eseguiti ad ogni check-in riducendo lo sforzo richiesto per scoprire la causa principale dei bug e correggerli man mano che vengono introdotti .

Ho avuto successo con l'unità testando la mia applicazione con MSTest e testando il mio Javascript con QUnit e raccogliendo i risultati di quei test con un singolo test dell'unità MSTest che utilizza WatiN (mi è stato suggerito Selenium , che ha anche la capacità di registrare i test, ma ha trovato WatiN migliore per automatizzare in modo pulito) e di utilizzarli per i test di regressione.

Non sono sicuro dell'idoneità di questo approccio per WPF.

Ho usato Moq per l'isolamento (una parte importante del test delle unità), vedi questo SO question on isolation framework per ulteriori alternative.

Controlla The Art Of Unit Testing per una buona introduzione su come testare bene l'unità e una buona discussione sulle alternative. Ho anche sentito che Lavorare efficacemente con il codice legacy è utile per aggiungere test unitari al codice esistente, ma non averlo ancora letto.