Test dell'unità nell'architettura VIPER: possibile?

Question

Test dell'unità nell'architettura VIPER: possibile?

#1 da (9 voti)

3

TL; DR Non ci sono metodi in VIPER che restituiscono alcun valore, quindi come testarli?

Ragionamento:

In VIPER, ogni livello comunica con un altro livello mantenendo un riferimento astratto ad esso (Protocolli / Interfacce).

Ad esempio, View ha riferimento a un Presenter. Se la vista chiama presenter.getSomething () presenter non restituirà immediatamente un valore. Invece, il presentatore avrà un riferimento di vista e, dopo aver completato le sue operazioni, il presenter chiamerà view.setSomething (qualcosa).

Questo flusso è coerente su tutti i flussi tra i livelli. E per parafrasarlo, le classi che implementano questi protocolli / interfacce, espongono solo i metodi che implementano da protocolli e interfacce come pubblici. Durante la scrittura di test puoi accedere solo a questi metodi pubblici e, tutti questi metodi restituiscono null.

L'argomento per cui è possibile restituire un valore non è sufficientemente valido nei casi reali in cui le operazioni eseguite dopo una chiamata devono essere asincrone, quindi deve utilizzare la struttura di callback di VIPER invece di restituire direttamente un valore su chiamata.

Tuttavia, ogni post di blog, articolo e video spiega che VIPER afferma che rende il codice testabile per TDD.

Modifica Esiste una domanda metodo di prova dell'unità vuota che può sembrare il duplicato di questo, ma la mia domanda riguarda il comportamento simile non come lo testiamo, ma come l'architettura limita l'approccio (a mio modo di vedere almeno).

design-patterns ios android architectural-patterns

posta Talha 27.04.2018 - 15:00

fonte

1 risposta

Leggi altre domande sui tag design-patterns ios android architectural-patterns

Come autore API, dovrei considerare Empty e Null lo stesso nei criteri di ricerca? È accettabile utilizzare un identificatore di chiave surrogata come parametro URL?

score 9 · Accepted Answer

Oh è possibile. Semplicemente non sembra quello che vuoi che assomigli.

Ciò di cui ti lamenti è l'uso delle porte di output ^{1 , 2 , 3} per comunicare risultati anziché restituire risultati. Questo rende più complicato il test? Sì. Allora perché farlo? Perché ti dà un altro strato di polimorfismo.

Quando return , tu stai tornando al chiamante. Non hai scelta. Nessun altro posto dove andare Ciò significa che il chiamante deve sapere come gestire il risultato. Se hai una porta di uscita puoi mandare il risultato a qualsiasi cosa sappia ascoltarti. È potente

Perché è così potente? Perché tu vai sempre avanti. Sempre rivolto verso l'astrazione. Usare le cose nel modo in cui dovevano essere usate piuttosto che nascondersi dietro di loro. Le astrazioni funzionano meglio quando non le stai violando.

Per testare questo devi sapere come progettare cose che sanno come ascoltare una porta di uscita. Ma lo avresti fatto comunque. Quindi qual è il problema?

Il problema è che molte persone vengono coinvolte nel pensare strutturalmente. "Tutto quello che sto facendo è verificare che sia stato chiamato un metodo". No. Stai verificando che un messaggio, che comunica un risultato, sia stato inviato. Se, in questo mini linguaggio di output, sembra una chiamata al metodo, bene. "Ma questo è un dettaglio di implementazione!" No. Fa parte del linguaggio della porta di uscita. Che cosa fa qualsiasi cosa con quel messaggio dipende da loro. Ciò che viene fatto è il dettaglio dell'implementazione.

"Ma è così difficile provare!" Beh, si. Ma hai deciso di usarlo quindi è colpa tua. "Quindi non dovrei mai usarlo?" No, dovresti usarlo quando fa qualcosa di utile per te, quando lo capisci e quando pensi che valga il dolore che provoca.