Come testare i modelli di unità nell'app MVC / MVR?

1

Sto costruendo un'app web node.js e sto provando a farlo per la prima volta in modo guidato dai test. Sto usando l'unità di nodo per i test, che trovo mi consente di scrivere test rapidamente e senza dolore. In questa particolare app, il sollevamento pesante consiste principalmente nel tradurre dati SQL in oggetti Javascript complessi e servirli al front-end tramite json. Allo stesso modo, l'app spende anche una grande quantità di codice per convalidare e tradurre oggetti JavaScript complessi e multidimensionali che riceve dal front-end in righe SQL. Quindi ho usato un modello di progettazione grassa per l'app - la maggior parte del codice reale risiede nei modelli, dove avviene la traduzione dei dati.

Qual è l'approccio migliore per testare tali modelli con i test unitari? Intendo in particolare i metodi che hanno creato oggetti javascript dalle righe SQL e li servono al front-end. In questo momento quello che sto facendo è fare particolari richieste dei miei modelli con i test unitari e controllare i dati restituiti per tutti i campi che dovrebbero essere lì. Tuttavia ho il sospetto che questo non sia il tipo di test più robusto che potrei fare. Il mio attuale progetto di test significa anche che devo impacchettare il mio codice app con alcuni dati fittizi in modo che i miei test possano anticipare il tipo di dati che l'app dovrebbe restituire quando vengono eseguiti i test.

DOMANDA AGGIORNATA:

Domanda specifica:

Ha senso iniettare un livello di test tra il mio modello e il mio database? O sarebbe meglio lasciare che i modelli funzionassero su un vero database con i dati di test predefiniti inseriti in esso?

La seconda opzione che immagino porterà probabilmente a test più accurati, ma il primo modello sembra più versatile in termini di granularità e rende i test e lo sviluppo più portabili (nessun db richiesto)

    
posta b.b. 29.05.2014 - 16:05
fonte

1 risposta

4

Crea un repository o un livello di servizio che funge da intermediario per il tuo modello e frontend e scrivi oggetti fittizi per quel livello del repository o del servizio.

Il Service Layer fornisce una superficie di interfaccia che puoi prendere in giro. È possibile iniettare un falso o uno stub che riproduca il comportamento del livello di servizio o utilizzare una libreria per creare oggetti fittizi. I livelli di dati non lo fanno bene perché, mentre rappresentano adeguatamente il dominio dei dati, non modellano adeguatamente i processi aziendali e, beh, chi vuole prendere in giro un DAL comunque?

Quindi, se crei un livello di servizio o un livello di repository, questo ti offre un livello di astrazione tra le tue classi di database e il tuo frontend. È quindi possibile prendere in giro quel livello di servizio e simulare il comportamento del servizio specifico del dominio aziendale per testare le tue classi frontend.

    
risposta data 29.05.2014 - 18:15
fonte

Leggi altre domande sui tag