2015-11-17 11 views
19

Sto provando a implementare alcuni test dell'interfaccia utente nel mio progetto. Tutto va bene purché sia ​​semplice: registra il caso di test, aggiungi alcune affermazioni, quindi esegui il test. Questo funziona bene, ma quando provo ad accedere al modulo applicativo da dentro la mia prova, il linker genera un errore (vedi sotto):Errore del linker durante l'accesso al modulo dell'applicazione nei test dell'interfaccia utente in XCode 7.1

Nel file sorgente dell'applicazione:

func foo() { 
    assert(true) 
} 

Nel test dell'interfaccia utente:

import XCTest 
@testable import MyApp 

func testExample() { 
    foo() 
} 

Errore:

Undefined symbols for architecture i386: "MyApp.foo() ->()", referenced from: MyAppUITests.MyAppUITests.testExample (MyAppUITests.MyAppUITests)() ->() in MyAppUITests.o ld: symbol(s) not found for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Undefined symbols for architecture x86_64: "MyApp.foo() ->()", referenced from: MyAppUITests.MyAppUITests.testExample (MyAppUITests.MyAppUITests)() ->() in MyAppUITests.o ld: symbol(s) not found for architecture x86_64

Ho riscontrato un problema simile riportato qui: https://forums.developer.apple.com/thread/20609 ma nessuna soluzione. Mi sembra che lo @testable semplicemente non funzioni correttamente. Il tizio su developer.apple.com ha provato a risolvere il problema aggiungendo Test Host e Bundle Loader nelle impostazioni, ma non penso che questo sia l'approccio corretto. Penso che lo @testable dovrebbe solo far funzionare tutto, e al momento non sembra proprio così. Qualsiasi aiuto apprezzato!

+0

Non dovresti accedere al modulo dell'applicazione come questo dai tuoi UITests .... ma se vuoi davvero (per favore non farlo) puoi selezionare la casella per la spedizione dei membri di destinazione nella finestra di ispezione dei file. Penserei che '@ testable' non funzioni in UITests, perché non dovresti accedere a funzioni raw come questa. – JMFR

+2

@JMFR puoi approfondire perché no? Per me questo è uno scenario perfetto, specialmente se si hanno alcune variabili statiche o metodi per controllare i test.Per quanto riguarda il tuo suggerimento di verificare l'appartenenza al target, questo è esattamente quello che volevo evitare usando '@ testable'. – lawicko

risposta

3

I test dell'interfaccia utente sono un modulo separato dall'app, pertanto non vengono eseguiti all'interno dell'app come farebbe un test logico. L'unico modo per condividere il codice è compilare tutti i file dell'app che è necessario condividere tra i due moduli. Controllare questo blog per come si può raggiungere che, https://www.bignerdranch.com/blog/ui-testing-in-xcode-7-part-1-ui-testing-gotchas/

trovato anche un radar depositato qui, https://openradar.appspot.com/23116258

28

@testable import MainModule non funzionerà per il test dell'interfaccia utente, anche se sarebbe consentire il completamento del codice (potrebbe farvi sentire funziona). È stato progettato solo per il test delle unità fino ad ora. E porterebbe a costruire il fallimento, qualcosa di simile:

ld: symbol(s) not found for architecture x86_64 
clang: error: linker command failed with exit code 1 (use -v to see invocation) 

La soluzione è aggiungere il file di codice sorgente per target di test dell'interfaccia utente, così, allora funzionerà fuori dalla scatola (anche senza @testable import).

Inspector File ->target appartenenza -> controllare UI di prova al bersaglio (in aggiunta a bersaglio principale)

Speranza di Apple lo risolverà presto in modo che possiamo avere un modo più pulito per utilizzarlo .

+0

Dopo circa 2 ore di sbattere la testa contro il muro questo mi ha salvato, grazie! – Josh

+0

@Josh contento che abbia aiutato :) –

Problemi correlati