workflow ios



Alla ricerca di uno schema decente per implementare l'ambiente di test di accettazione utilizzando le tecnologie native Objective-C e Mac (1)

KIF e il porto di Jasmine - Cedar per iOS funzionano abbastanza bene dalla mia esperienza.

Tuttavia, ho anche avuto un sacco di buon uso di zucca , che come Frank, è alimentato da cetriolino.

sfondo

Sto cercando un modo per implementare uno schema simile a quello utilizzato da Frank per implementare "Test di accettazione automatici per app native iOS", ma voglio che questo schema si basi su tecnologie native iOS / MacOSX. TLDR scusiamo per il seguente TLDR ma merita una spiegazione dettagliata.

1. Ecco una breve panoramica di come funziona Frank:

ha parti Client e Server.

La parte server è incorporata in un'applicazione a cui vogliamo eseguire test di accettazione. Le esercitazioni di Frank ci mostrano come creare una destinazione duplicata della destinazione principale di un'app e incorporare il server HTTP Frank su di essa.

Parte client - è principalmente un Cetriolo che esegue scenari di testo semplice: ogni scenario contiene direttive che devono essere eseguite su un'app (riempire il campo di testo, toccare il pulsante, assicurarsi che esista un elemento specifico in una pagina, ecc ...). Inoltre, ogni scenario avvia la propria istanza di app in questo modo fornendo uno stato nuovo ogni volta che entriamo in un nuovo scenario.

Client (ponte Cetriolo e Rubino-Obiettivo-C) comunica con Server (server HTTP incorporato in un'app) tramite protocollo HTTP. Usa le convenzioni speciali in modo che il client possa dire al server cosa deve fare un'app in modo da poter eseguire lo scenario specifico.

2. Recentemente ho trovato il seguente articolo scritto dall'autore di Frank Pete Hodgson:

http://blog.thepete.net/blog/2012/11/18/writing-ios-acceptance-tests-using-kiwi/

In cui suggerisce un modo più semplice di scrivere test di accettazione per gli sviluppatori che non amano affidarsi a strumenti esterni come Cucumber e Ruby. Lasciatemi citare l'autore stesso:

Prima di iniziare, vorrei essere chiaro che personalmente non utilizzerei questo approccio per scrivere test di accettazione. Preferisco di gran lunga usare un linguaggio di livello superiore come Ruby per scrivere questo tipo di test. Il codice di prova è molto meno elaborato e molto più espressivo, supponendo che tu stia bene con il rubino. Ed è per questo che ho voluto provare questo esperimento. Ho parlato con alcuni sviluppatori iOS nel corso del tempo che non si sentono a proprio agio nello scrivere test in ruby. Sono più a loro agio in Objective-C di qualsiasi altra cosa e vorrebbero scrivere i loro test nella stessa lingua che usano per il loro codice di produzione. Giusto.

Questo post sul blog mi ha ispirato a sviluppare rapidamente il mio strumento molto grezzo e primitivo che fa esattamente quello che Pete ha descritto nel suo post sul blog: NativeAutomation .

In effetti, come è stato descritto da Pete, è possibile eseguire test di accettazione utilizzando solo l'impostazione Kiwi / PublicAutomation collocata in un semplice target OCTests. Mi è piaciuto molto perché:

  • È solo puro C / Objective-C. È stato molto facile creare un gruppo iniziale di assistenti di C, che assomigliano agli aiutanti di Capybara :

tapButtonWithTitle, fillTextFieldWithPlaceholder, hasLabelWithTitle e così via ...

  • Non richiede strumenti e linguaggi esterni: non è necessario in Cetriolo / Rubino o altro. NativeAutomation utilizza solo PublicAutomation che usa anche Frank. PublicAutomation è necessario per simulare le interazioni dell'utente sullo schermo di un'applicazione: tocchi, riempimenti, gesti ...

  • È molto utile eseguire questi test direttamente da Xcode semplicemente eseguendo un pacchetto Test unitari Cocoa. (Anche se le build da riga di comando sono facili).

Problema

Il problema dell'approccio Kiwi/PublicAutomation è che l'intera suite di test è incorporata nel pacchetto dell'app. Significa che dopo l'esecuzione di ogni scenario, non è possibile reimpostare l'applicazione in modo che sia in uno stato nuovo prima che lo scenario successivo inizi l'esecuzione. L'unico modo per aggirare questo problema è scrivere Kiwi's beforeEach hook con un metodo che esegue un soft-reset di un'applicazione come:

+ (void)resetApplication {
[Session invalidateSession];
[LocationManager resetInstance];

[((NavigationController *)[UIApplication sharedApplication].delegate.window.rootViewController) popToRootViewControllerAnimated:NO];

[OHHTTPStubs removeAllStubs];

cleanDatabase();

shouldEventuallyBeTrue(^BOOL{
    return FirstScreen.isCurrentScreen;
});

ma in caso di applicazioni che coinvolgono networking, lavori asincroni, dati core, operazioni sui file diventa difficile eseguire un vero e proprio teardown di un materiale lasciato dallo scenario precedente.

Domanda

Il problema sopra descritto mi ha fatto pensare se fosse possibile implementare un approccio più complesso simile all'approccio di Frank, con una seconda app che funziona indipendentemente dal bundle dell'app principale e che non si basa su strumenti esterni come Cucumber (Ruby).

Ecco come vedo il modo in cui potrebbe essere fatto.

Oltre a un'app principale (MainApp), c'è una seconda app iOS (o Mac OS X) (AcceptanceTestsRunnerApp) che contiene l'intera suite di test di accettazione e che esegue questa suite contro un pacchetto di app principale:

Attiva la nuova istanza del simulatore prima che entri in ogni nuovo scenario ed esegue lo scenario corrente contro l'istanza dell'app del simulatore corrente.

La domanda è:

Non sono ben informato sulle tecnologie Mac OSX o iOS che mi consentiranno di farlo: non so se sia addirittura possibile configurare un'applicazione Mac OS X / iOS (AcceptanceTestsRunnerApp) che potrebbe assumere il controllo di un'app principale (MainApp) ed eseguire scenari di test di accettazione contro di esso.

Sarò grato per qualsiasi pensiero / suggerimento che le persone che si sentono più a proprio agio con lo strumento Objective-C nativo per la scrittura di test di accettazione per le applicazioni iOS potrebbero avere.

AGGIORNATO PIÙ TARDI

... Ho letto alcuni documenti sui servizi XPC ma l'ironia è che lo schema che sto cercando dovrebbe essere completamente opposto allo schema che la documentazione di XPC suggerisce:

Idealmente voglio che la mia AcceptanceTestsRunnerApp domini su MainApp: eseguila e controllala (interazioni dell'utente, asserzioni sulla gerarchia delle viste) tramite alcuni proxy dell'oggetto al delegato dell'applicazione MainApp mentre l'installazione dei servizi XPC presuppone che il servizio XPC (AcceptanceTestsRunnerApp) sia subordinato a un'app (MainApp ) e richiederà il servizio XPC per vivere all'interno del pacchetto dell'app che voglio evitare con tutti i mezzi.

... La mia attuale lettura è argomenti di programmazione di oggetti distribuiti . Mi sembra che troverò la mia risposta lì. Se nessuno mi fornisce guide o indicazioni, invierò una risposta sulle mie ricerche e pensieri.

... Questo è il prossimo passo nella mia ricerca: Oggetti distribuiti su iOS .





frank