Non dovrebbe NSUserDefault essere una lavagna pulita per i test unitari?

Question

Sto scrivendo i miei primi test dell'unità iOS (Xcode 5, iOS 6) e ho riscontrato che i risultati dei test delle unità variano a seconda di ciò che ho fatto ultimamente nel Simulatore. Per esempio. Clicco su un utente nel mio elenco di contatti nel simulatore, e ora i miei dati "contatti recenti" in UserDefaults hanno un oggetto in più rispetto a prima, anche quando eseguo test unitari.

Per il test delle unità, non è pulito avere dati di default dell'utente casuali (sono abituato ai test RoR con il proprio db pulito). Inoltre, potrei voler testare stati specifici come avere dati "contatti recenti" vuoti.

Dall'esaminare le domande correlate qui, mi sembrano alcune possibili risposte di cui non sono contento.

• Mock UserDefaults per i test di unità! Dovrei modificare molte classi esistenti in modo da poter iniettare quella finta.
• Cancella o personalizza UserDefaults in un metodo setUp! Ma poi i miei dati creati faticosamente nei test manuali sarebbero andati.
• Cancella o personalizza UserDefaults in un metodo setUp quindi ripristina quei valori in tearDown! Ahia.

Questi sembrano inutilmente complicati per qualcosa che dovrebbe essere una pratica standard nei test unitari. Non voglio ripetermi in ogni test unitario. Quindi, le mie domande sono:

• Mi manca qualcosa di desiderabile sul modo in cui gli UserDefaults vengono mantenuti dal test del Simulatore ad-hoc fino alle unit test runs?
• Esiste un modo configurabile per risolvere questo problema, ad esempio un modo per impostare l'obiettivo del test dell'unità in modo che disponga di un percorso di memorizzazione diverso per UserDefaults rispetto a quando utilizzo il simulatore per eseguire il test manuale?
• In caso contrario, c'è un modo elegante per farlo in codice?
• Ad esempio, potrei avere un oggetto MyAppTestCase ereditato da XCTestCase e sovrascrivere i metodi setUp e tearDown per sempre mettere da parte quindi ripristinare UserDefaults. E 'questa una buona idea?

Answer 1

L'utilizzo di suite denominate like in this answer ha funzionato bene per me. La rimozione delle impostazioni predefinite dell'utente utilizzate per il test potrebbe essere eseguita anche in func tearDown().

class MyTest : XCTestCase { 
    var userDefaults: UserDefaults? 
    let userDefaultsSuiteName = "TestDefaults" 

    override func setUp() { 
     super.setUp() 
     UserDefaults().removePersistentDomain(forName: userDefaultsSuiteName) 
     userDefaults = UserDefaults(suiteName: userDefaultsSuiteName) 
    } 
} 

Answer 2

Come suggerisce @Till, il progetto è probabilmente errato per una buona testabilità. Piuttosto che disporre di pezzi del sistema verificabili unitariamente, leggere direttamente NSUserDefaults, dovrebbero funzionare con qualche altro oggetto (che può parlare con NSUserDefaults). Questo è più o meno equivalente a "beffardo NSUserDefaults", ma è davvero un livello di astrazione extra. Il tuo oggetto di configurazione avrebbe astratto sia NSUserDefaults che altra memoria di configurazione come il portachiavi. Garantirebbe inoltre di non disperdere costanti di stringa attorno al programma. Ho costruito questo tipo di oggetto di configurazione per molti progetti e lo consiglio vivamente.

Alcuni sostengono che gli oggetti testabili sull'unità non dovrebbero fare affidamento su singoletti come NSUserDefaults o sul mio oggetto di configurazione globale "configurazione". Invece, tutta la configurazione dovrebbe essere iniettata su init. In pratica, trovo questo per creare troppo mal di testa quando si interagisce con gli Storyboard, ma vale la pena considerare in luoghi in cui può essere utile.

Se si vuole veramente scavare a fondo in NSUserDefaults, fornisce alcune funzionalità di stratificazione. È possibile esaminare setVolatileDomain:forName: per vedere se è possibile creare un livello aggiuntivo per il test dell'unità. In pratica, non ho avuto molta fortuna con questo genere di cose su iOS (molto di più su Mac, ma ancora non al livello di cui avresti bisogno per crederci).

È possibile swizzle standardUserDefaults, ma non consiglierei questo approccio se è possibile evitarlo. Il tuo "salva tutto all'inizio e ripristina tutto alla fine" è probabilmente il modo migliore standardizzato per affrontare il problema se non riesci ad adattare il tuo design per evitare esternalità.

Answer 3

Disponibile iOS 7/10,9

Invece di utilizzare i standardUserDefaults è possibile utilizzare un nome interno per caricare il tuo test

[[NSUserDefaults alloc] initWithSuiteName:@"SomeOtherTests"]; 

Questa accoppiata con un certo codice per rimuovere il file SomeOtherTests.plist dal appropriata directory in setUp archivierà il risultato desiderato.

Dovresti progettare qualsiasi oggetto per prendere gli oggetti di default in modo che non ci siano effetti collaterali dai test.

Answer 4

Si può facilmente salvare & ripristinare il dominio persistente per l'identificatore del fascio principale, che è quello che [[NSUserDefaults standardUserDefaults] setObject:forKey:] scrive a. Ad esempio,

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; 
NSDictionary *originalValues = [defaults persistentDomainForName:[[NSBundle mainBundle] bundleIdentifier]]; 

// do stuff, possibly [defaults removePersistentDomainForName:[[NSBundle mainBundle] bundleIdentifier]] 
// or using setPersistentDomain: to substitute a dictionary of mock values and test against that 

[defaults setPersistentDomain:originalValues forName:[[NSBundle mainBundle] bundleIdentifier]]; 

È inoltre possibile utilizzare [[NSUserDefaults standardUserDefaults] volatileDomainForName:NSRegistrationDomain] se si desidera accedere a un unico dizionario combinato della roba che si registra utilizzando tutte le -registerDefaults: chiamate (almeno per qualsiasi codice che ha eseguito fino al punto in cui il test di unità ha iniziato, ovviamente).

Answer 5

Mi piace creare un nuovo così non c'è collusione.

import XCTest 

extension UserDefaults { 
    private static var index = 0 
    static func createCleanForTest(label: StaticString = #file) -> UserDefaults { 
     index += 1 
     let suiteName = "UnitTest-UserDefaults-\(label)-\(index)" 
     UserDefaults().removePersistentDomain(forName: suiteName) 
     return UserDefaults(suiteName: suiteName)! 
    } 
} 

class MyTest: XCTestCase { 

    func testOne() { 
     let userDefaults = UserDefaults.createCleanForTest() 
     XCTAssertFalse(userDefaults.bool(forKey: "foo")) 
     userDefaults.set(true, forKey: "foo") 
     XCTAssertTrue(userDefaults.bool(forKey: "foo")) 
    } 

    func testTwo() { 
     let userDefaults = UserDefaults.createCleanForTest() 
     XCTAssertFalse(userDefaults.bool(forKey: "foo")) 
     userDefaults.set(true, forKey: "foo") 
     XCTAssertTrue(userDefaults.bool(forKey: "foo")) 
    } 
}