2013-07-19 90 views
5

Sto provando a eseguire il test retrospettivo dell'unità un'applicazione abbastanza complessa ma che utilizza MVC. So che applicare i test unitari in modo retrospettivo non è l'ideale, ma credo ancora che sia possibile rifattorizzando il codice esistente. Nella maggior parte dei casi non è possibile testare un'unità su un'unità, senza fare affidamento su altre unità, ad esempio una vista si basa su un modello.In che modo i test unitari possono essere modulari quando dipendono da altre unità?

Qual è il modo migliore per eseguire il test dell'unità in questo caso? È meglio utilizzare il modello reale o creare un modello fittizio?

Il problema con l'utilizzo di un modello reale nella mia situazione è che il modello si basa su altre classi di risposta che ottengono dati da XML, quindi c'è una catena di dipendenza. Questo modello ha molti dati quindi sarebbe molto più semplice da usare, ma forse mi manca il punto.

Ho fornito un UML dell'applicazione per brevità.

enter image description here

** Modifica ****

Ok, quindi se non sbaglio, è buona norma creare dati finti all'interno di una classe finta? Per esempio io ho la classe finta "MockPlaylistPanelModel" che crea i dati richiesti per la classe View "PlaylistPanel" per eseguire senza errori:

class MockPlaylistPanelModel extends Mock implements IPlaylistPanelModel 
{ 
    /** 
    * Return all playlist items 
    * @public 
    */ 
    public function get mainPlaylistItems():Vector.<PlaylistData> 
    { 
    var playData:Vector.<PlaylistData> = new Vector.<PlaylistData>; 
    var playlistResp:PlaylistData = new PlaylistData(0, "", "", 0, 0, 0, 0); 
    playData.push(playlistResp); 
    return playData; 
    } 

} 

risposta

6

Per adattare in modo retrospettivo il test dell'unità a un'applicazione esistente, è spesso necessario modificare il codice dell'applicazione per supportare il test dell'unità (come giustamente menzionate potrebbe essere necessario eseguire alcuni refactoring). Tuttavia, ovviamente, il rischio qui è che le modifiche all'applicazione introducono bug, che non possono essere protetti senza avere alcuni test in atto.

Pertanto, un approccio sensato consiste nell'ottenere alcuni test di livello del sistema che riguardano alcuni dei vostri casi d'uso principali. Questo agisce come una sorta di "scaffold di test" attorno alla tua applicazione, il che significa che puoi iniziare più sicuro a introdurre test di livello inferiore con un rischio ridotto di introdurre bug mentre modifichi l'applicazione per renderla più testabile. Una volta implementato, è possibile introdurre una politica in base alla quale gli sviluppatori devono scrivere test su qualsiasi codice che modificano prima di cambiarlo: ciò consente di sviluppare organicamente una serie di test automatizzati intorno all'applicazione.

Consiglio vivamente di prendere in consegna Working Effectively with Legacy Code - questo eccellente libro copre tutti i tipi di tecniche utili per l'introduzione del test in un'applicazione esistente che ha pochi test automatici.

Per quanto riguarda la domanda sulla possibilità di creare dati di simulazione all'interno di una classe di simulazione per il test, questo è un approccio che è possibile adottare quando si iniettano versioni di prova di oggetti, ma probabilmente non il migliore. Usando una struttura di simulazione come Mockito è possibile creare facilmente oggetti finti con comportamento chiaramente definito al volo. Nel tuo caso, puoi usare Mockito per creare un'implementazione del modello di simulazione, e quindi iniettare il tuo modello di simulazione in qualunque oggetto dipenda da esso.

+0

+1 per il riferimento del libro, +1 per Mockito, +1 per una buona risposta - peccato posso solo votare una volta ... – weltraumpirat

0

non sono test di unità; sono test di integrazione.

Sì, utilizzare i mock per isolare le classi per i test unitari.

0

Un test di unità deve testare solo una parte del programma. Se usi le altre parti diventa test di integrazione.

Un test di integrazione verifica che le parti funzionino bene insieme e non facciano ciò che devono fare.

Un test dell'unità verifica che la parte faccia ciò che deve fare.

Che differenza tra le due prove.

Al refactoring per il test dell'unità è possibile cercare il modello di progettazione Dipendenza iniezione.