Come posso testare i controller di visualizzazione iOS dell'unità?

Question

Come si suppone che un'unità test i miei controller di visualizzazione (sottoclassi UIViewController) in un'app iOS?

Ho discusso ampiamente questo argomento negli ultimi due giorni ma non riesco ancora a capire quale sia il modo corretto di farlo.

Sembra che ci sono almeno tre modi di logica vista del regolatore unit testing:

• esporre le azioni private e IBOutlets che si desidera test di unità (dichiararle nel file di intestazione).

• Utilizzare una categoria, come Tests, per accedere a azioni private e IBOutlet dai test di unità.

• Non esporre nulla, anziché trovare pulsanti e altre visualizzazioni per titolo o un'altra proprietà pubblica e simulare l'interazione dell'utente tramite metodi pubblici di visione UIV (ad esempio, simulare l'utente toccando un pulsante); quindi osserva lo stato visibile.

  Non ho trovato molte fonti su questo, ma c'è un esempio su objc.io.

Ora, ad essere onesti, non mi piace molto i primi due perché per quanto ho capito unit test non sono tenuti a testare interni dell'oggetto (vale a dire metodi privati), e dichiarando pubblica solo per il il gusto dei test non sembra la migliore pratica. Di solito mantengo IBActions e IBOutlets all'interno dell'implementazione ma ora devo improvvisamente rendere tutto pubblico solo perché sto aggiungendo test ...

Penso che ci possa essere un'altra alternativa: spostare la maggior logica possibile dal mio punto di vista controllori in componenti indipendenti e testarli invece (lasciando i test non testati o per lo più non testati). Questa mi sembra una buona idea, ma dovrò fare molti refactoring (sto attualmente aggiungendo i test unitari per un progetto che non è stato codificato con i test in mente).

Quindi mi chiedevo, qual è il modo migliore di testare i controller di visualizzazione?

Answer 1

Questa domanda può essere principalmente basata sull'opinione pubblica e dovrebbe essere chiusa, ma pubblicherò comunque alcune delle mie opinioni.

IBAction e IBOutlet non sono un metodo/proprietà veramente privato. Potresti essere in grado di dichiararli come metodo/proprietà privata ma concettualmente sono l'interfaccia pubblica del tuo controller di visualizzazione. Sono il modo di comunicare con le opinioni. Pertanto, preferirò il secondo modo, utilizzare una categoria, come UI, per accedere a azioni private e IBOutlet dai test unitari.

Sono totalmente contro la terza via per i test unitari. Perché per definizione, stai scrivendo test di integrazione piuttosto che unit test. Fa molto affidamento sui dettagli di implementazione e può rompersi facilmente. Potresti volerne alcuni, ma prima dovresti fare i test unitari.

La vera soluzione, come già sapete, è il refactoring del codice per renderli testabili. Idealmente, il controller dovrebbe essere molto piccolo e agisce solo come associazione tra vista e modelli. Se si dispone di un controller di grandi dimensioni, è necessario rifattorizzare la logica dell'interfaccia utente nel modello di visualizzazione/visualizzazione e nella logica di business in helper modello/modello.