Soluzione alternativa per il test delle unità Core Data in Swift

Question

Soluzione alternativa per il test delle unità Core Data in Swift

#1 da (1 voti)
#2 da (0 voti)

1

Sono ancora abbastanza nuovo alla programmazione, ma la mia prima app è stata recentemente approvata ed è ora in vendita su App Store. La mia app utilizza Core Data ed è scritta in Swift. Dopo alcune difficoltà iniziali, decido di scrivere l'app senza test unitari. Ora vorrei implementare i test unitari per prevenire la regressione.

I miei oggetti gestiti sono creati all'interno di metodi di classe nelle mie sottoclassi NSManagedObject e usano una variabile globale "contesto" che dichiaro in AppDelegate per memorizzare NSManagedObjectContext creata nel codice predefinito di Apple. So che le variabili globali sono generalmente scoraggiate, ma questo approccio ha più senso per me, è facile da scrivere e non ha lasciato alcun bug o altri problemi all'interno della stessa app. Sfortunatamente, questo rende difficile il test dell'unità. Ho provato diversi approcci alla creazione di uno stack di Core Data all'interno del mio target di test, ma non riesco a ottenere nulla da lavorare senza riscrivere un sacco di codice della mia app. Non voglio davvero farlo solo per renderlo testabile. Ho preso in considerazione l'utilizzo di framework come Quick / Nimble o Magical Record, ma non vedo come ciò possa aiutare il mio problema.

Ho trovato una soluzione alternativa, ma sono curioso che la gente pensi che sia una cattiva idea: ho creato una classe nel mio obiettivo principale (non test) chiamato TestingClass . Nel mio primo ViewController viewDidAppear , chiamo il metodo startTests . TestingClass è scritto in stretto Swift senza quadri di test. Ho diverse affermazioni che dovrebbero essere false. Se sono veri, aggiungono una stringa a un array. Al termine dei test, se il numero di array è > 0, stampa i contenuti e interrompe.

Sto pensando di usarlo fino a quando il mio aggiornamento è pronto per la spedizione. Quando lo è, disabiliterò TestingClass e rimuoverò la mia chiamata. Sono curioso di sapere se qualcuno ha mai fatto qualcosa del genere. Dovrei solo capire un modo per fare i test il modo "giusto"?

unit-testing ios swift-language xcode

posta Steve S 25.12.2014 - 23:48

fonte

2 risposte

Leggi altre domande sui tag unit-testing ios swift-language xcode

Esportazione ideale in termini di dimensioni per le definizioni di moduli asincroni in JavaScript? Blocco dei dati rispetto al blocco delle funzioni

score 1 · Answer 1

Diamo prima una domanda più ampia. In qualche modo, la tua domanda si riduce all'equilibrio del pragmatismo rispetto al "modo migliore" teorico per la codifica. Sono nel campo di programmazione pragmatico, specialmente con la tua situazione particolare. La codifica pragmatica significa che aggiriamo i limiti imposti dall'attuale stack di software.

Nel tuo caso particolare, con la tua particolare comprensione dello stack, stai incontrando una sfida. Hai identificato un work-around e hai fatto funzionare le cose per il momento. Parte di queste sfide potrebbe essere introdotta dall'uso di variabili globali, ma come hai affermato, aveva senso per le informazioni che dovevano essere memorizzate.

Penso che l'utilizzo di TestingClass sia un approccio perfettamente valido dal momento che stai adempiendo allo scopo di test (assicurandoti che le cose funzionino come previsto) e stai anche lavorando all'interno dei vincoli, come li hai capiti, dell'applicazione hai creato. Certamente non saresti il primo a mettere in atto un cablaggio di test durante lo sviluppo e poi rimuoverlo prima di rilasciare l'app.

Esegui alcuni rischi con questo approccio. Nello specifico, se ti dimentichi di disabilitare quella classe prima di rilasciarla in produzione, ciò potrebbe creare problemi per te. Allo stesso modo, è effettivamente necessario duplicare tutto il codice tra il percorso principale e il percorso di test. Quindi si corre il rischio di un errore di escape se il percorso di test non riflette esattamente come opera il percorso principale. Infine, costruisce casi di test complessi che possono essere più difficili da eseguire il debug perché devi recuperare le cose per capire dove si è rotto.

Quindi, per quanto riguarda l'approccio particolare che hai preso, è abbastanza valido.

Potrebbe non essere "puro" nel senso di seguire test unitari tradizionali e automatizzati, ma penso che il pragmatismo debba governare il giorno. Le persone non acquistano la tua applicazione a causa dei test unitari, acquistano la tua app perché funziona. Il tuo approccio al test delle unità fornisce test di regressione e ti consente di concentrarti sullo sviluppo di nuove funzionalità.

score 0 · Answer 2

Può essere estremamente difficile codificare un codice di test basato su framework di sistema complessi, anche per programmatori esperti. Proverei a testare più codice possibile.

(inoltre, non inserire mai il codice che devi modificare manualmente tra le versioni di debug e di rilascio! È inevitabile che tu commetta un errore da qualche parte)