Qual è la risposta al mio problema di test dell'unità durante l'impostazione delle dipendenze fittizie?

1

Sto cercando di implementare l'architettura VIPER su iOS in Swift.

Il problema che ho è come impostare il grafico dell'oggetto. Si prega di ignorare il router e l'entità in quanto non è rilevante per il mio problema. Questo ci lascia con Interactor, Presenter e View.

Interactor - business logic, ha stato, funziona, accetta comandi. Presenter: trasforma i dati astratti in formato di presentazione o chiedi agli interactor di lavorare. Visualizza: presenta informazioni presentabili, invia azioni a Presenter per tradurre richieste di business logic.

La comunicazione tra questi tre componenti è bidirezionale e Interact e View non sono a conoscenza l'uno dell'altro:
    Interactor < - > Presentatore < - > View.

Tutti sono definiti come protocolli. (interfacce in altre lingue ...) Ogni componente concreto è conforme al relativo protocollo (cioè implementa un'interfaccia) ... e tali componenti solo si vedono come interfacce.

Ecco il problema:

Affinché il relatore funzioni correttamente, deve semplicemente avere un riferimento a un'istanza Interactor in cui si trovano la logica e lo stato dell'attività. Lo stesso vale per la vista, non può funzionare correttamente senza un riferimento a un'istanza di Presenter correttamente inizializzata.

Ho due opzioni:

OPZIONE A: 1) Il relatore avrà un inizializzatore richiesto che prenderà in considerazione un'istanza interactor. 2) La vista avrà un inizializzatore richiesto che prenderà in considerazione un'istanza presentatore. 3) Farò rispettare questo nei protocolli.

OPZIONE B: 1) Sul presentatore verrà visualizzata una variabile .interactor pubblica, che sarà impostabile su un'istanza presentatore. 2) Ci sarà una variabile publicpresenter sulla vista, e questo sarà impostabile in una istanza di visualizzazione.

L'opzione A con gli inizializzatori mi fornisce un meccanismo che garantisce che le cose siano impostate nel giusto ordine e che siano inizializzate in uno stato valido. Tuttavia, questo porta a dover replicare lo stesso meccanismo nei test unitari in cui i mock, le implementazioni di stub di quei protocolli devono effettivamente avere quegli inizializzatori e inizializzarsi l'uno con l'altro..quello significa che ora ho una catena di mock che dipendono l'una dall'altra che odora .

L'opzione B previene il problema con una catena di mock, ma in questo caso avrò potenzialmente degli oggetti in stato non valido, o devo testare effettivamente i metodi del router che imposta la catena delle dipendenze. Ma poi potrò occuparmi solo di uno strato di mock per ogni caso di test unitario. Almeno in teoria, penso, non l'ho ancora provato.

Quale approccio è corretto? O c'è qualche altro approccio? Potete consigliare per favore?

    
posta Earl Grey 08.10.2016 - 16:05
fonte

1 risposta

0

Le dipendenze del Presentatore concreto su un'istanza Interactor e della vostra vista concreta su un'istanza di Presenter non sono dipendenze che sono intrinsecamente parte delle rispettive interfacce.
Piuttosto, sono requisiti dalle vostre lezioni concrete di implementazione.
Ad esempio, un finto Presenter può perfettamente fare il suo lavoro senza avere un'istanza Interaction.

Ciò significa che l'implementazione corretta sarebbe vicina all'opzione A, ma senza inserire questo requisito nei protocolli.
In questo modo, è impossibile per il router (che ha bisogno di conoscere le classi concrete in ogni caso se questa è la presentazione di Presenter e View) per creare una vista o un relatore senza i collegamenti richiesti, ma si evita la catena di dipendenze nei test .

    
risposta data 08.10.2016 - 16:37
fonte

Leggi altre domande sui tag