iphone - driven - wikipedia bdd




Test/specifiche iOS TDD/BDD e test di integrazione e accettazione (6)

Quali sono le migliori tecnologie da utilizzare per lo sviluppo orientato al comportamento su iPhone? E quali sono alcuni esempi di progetti open source che dimostrano l'uso corretto di queste tecnologie? Ecco alcune opzioni che ho trovato:

Test unitario

Test::Unit Stile Test::Unit

  1. OCUnit/SenTestingKit come spiegato nella Guida allo sviluppo iOS: Applicazioni di test unitari e altri riferimenti OCUnit .
  2. CATCH
  3. GHUnit
  4. Google Toolbox per Mac: test delle unità iPhone

Stile RSpec

  1. Kiwi (che viene anche con beffa e aspettative)
  2. Cedar
  3. Jasmine con UI Automation, come mostrato nelle dettagliate specifiche di iOS-Acceptance-Testing

Test di accettazione

Stile Selenium

  1. UI Automation (funziona sul dispositivo)

    AGGIORNAMENTO: Zucchini Framework sembra fondere Cucumber & UI Automation! :)

    Vecchi post del blog:

  2. UISpec con UISpecRunner

  3. FoneMonkey

Stile di Cucumber

  1. Frank e iCuke (basati su Cucumber incontra l'iPhone )

  2. KIF (Keep It Functional) di Square

  3. Zucchini Framework utilizza la sintassi di Cucumber per i test di scrittura e utilizza CoffeeScript per le definizioni dei passaggi.

aggiunte

Conclusione

Beh, ovviamente, non c'è una risposta giusta a questa domanda, ma ecco cosa scelgo di seguire attualmente:

Per il test delle unità, OCUnit/SenTestingKit in XCode 4. È semplice e solido. Ma preferisco il linguaggio di BDD su TDD ( perché RSpec è meglio di Test :: Unit ?) Perché le nostre parole creano il nostro mondo. Quindi ora utilizzo Kiwi con il completamento del codice ARC e Kiwi / completamento automatico . Preferisco Kiwi su Cedar perché è costruito su OCUnit e viene fornito con abbinamenti e mock / stub in stile RSpec. AGGIORNAMENTO: Sto ora esaminando OCMock perché, al momento, Kiwi non supporta gli oggetti a ponte senza pedaggio .

Per il test di accettazione, utilizzo l'automazione dell'interfaccia utente perché è fantastico. Ti consente di registrare ogni caso di test, rendendo automatici i test di scrittura. Inoltre, Apple lo sviluppa, e quindi ha un futuro promettente. Funziona anche sul dispositivo e da Strumenti, il che consente altre interessanti funzionalità, come la visualizzazione di perdite di memoria. Sfortunatamente, con UI Automation, non so come eseguire il codice Objective-C, ma con Frank & iCuke puoi farlo. Quindi, UIButton materiale Objective-C di livello inferiore con i test unitari, o creerò UIButton solo per la configurazione di build TEST , che, quando si fa clic, eseguirà il codice Objective-C.

Quali soluzioni usi?

domande correlate


tl; dr

In Pivotal abbiamo scritto Cedar perché usiamo e amiamo Rspec sui nostri progetti Ruby. Cedar non è destinato a sostituire o competere con OCUnit; ha lo scopo di portare la possibilità di test in stile BDD all'Obiettivo C, proprio come Rspec è stato pioniere dei test in stile BDD in Ruby, ma non ha eliminato Test :: Unit. Scegliere l'uno o l'altro è in gran parte una questione di preferenze di stile.

In alcuni casi abbiamo progettato Cedar per superare alcune carenze nel modo in cui OCUnit lavora per noi. In particolare, volevamo essere in grado di utilizzare il debugger nei test, eseguire test dalla riga di comando e in build di elementi della configurazione e ottenere risultati di output del testo utili. Queste cose potrebbero essere più o meno utili per te.

Risposta lunga

Decidere tra due framework di test come Cedar e OCUnit (per esempio) si riduce a due cose: stile preferito e facilità d'uso. Inizierò con lo stile, perché è semplicemente una questione di opinioni e preferenze; la facilità d'uso tende ad essere un insieme di compromessi.

Le considerazioni sullo stile trascendono la tecnologia o il linguaggio che usi. x Il testing delle unità in stile è stato molto più lungo rispetto ai test in stile BDD, ma quest'ultimo ha rapidamente guadagnato popolarità, in gran parte grazie a Rspec.

Il vantaggio principale dei test in stile xUnit è la sua semplicità e l'ampia adozione (tra gli sviluppatori che scrivono i test delle unità); quasi tutte le lingue in cui è possibile prendere in considerazione la scrittura di un codice hanno a disposizione un framework in stile xUnit.

I framework in stile BDD tendono ad avere due differenze principali rispetto allo stile xUnit: come strutturate il test (o le specifiche) e la sintassi per scrivere le asserzioni. Per me, la differenza strutturale è il principale elemento di differenziazione. I test xUnit sono unidimensionali, con un metodo setUp per tutti i test in una determinata classe di test. Le classi che testiamo, tuttavia, non sono unidimensionali; spesso abbiamo bisogno di testare azioni in diversi contesti diversi, potenzialmente conflittuali. Ad esempio, considera una semplice classe ShoppingCart, con un metodo addItem: (per gli scopi di questa risposta userò la sintassi Objective C). Il comportamento di questo metodo può variare quando il carrello è vuoto rispetto a quando il carrello contiene altri articoli; può differire se l'utente ha inserito un codice di sconto; può differire se l'articolo specificato non può essere spedito dal metodo di spedizione selezionato; ecc. Quando queste possibili condizioni si intersecano l'una con l'altra si finisce con un numero geometricamente crescente di possibili contesti; nei test in stile xUnit questo porta spesso a molti metodi con nomi come testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. La struttura dei framework in stile BDD consente di organizzare singolarmente queste condizioni, che a mio avviso rendono più semplice accertarsi che io copra tutti i casi e che sia più facile trovare, modificare o aggiungere condizioni individuali. Ad esempio, usando la sintassi di Cedar, il metodo sopra sarebbe simile a questo:

describe(@"ShoppingCart", ^{
    describe(@"addItem:", ^{
        describe(@"when the cart is empty", ^{
            describe(@"with no discount code", ^{
                describe(@"when the shipping method applies to the item", ^{
                    it(@"should add the item to the cart", ^{
                        ...
                    });

                    it(@"should add the full price of the item to the overall price", ^{
                        ...
                    });
                });

                describe(@"when the shipping method does not apply to the item", ^{
                    ...
                });
            });

            describe(@"with a discount code", ^{
                ...
            });
        });

        describe(@"when the cart contains other items, ^{
            ...
        });
    });
});

In alcuni casi troverai contesti contenenti gli stessi gruppi di asserzioni, che puoi ASCIUGARE usando contesti di esempio condivisi.

La seconda differenza principale tra framework in stile BDD e framework xUnit-style, sintassi assertion (o "matcher"), rende semplicemente più bello lo stile delle specifiche; ad alcune persone piace molto, ad altri no.

Ciò porta alla domanda di facilità d'uso. In questo caso, ogni framework ha i suoi pro e contro:

  • OCUnit è in circolazione molto più a lungo di Cedar ed è integrato direttamente in Xcode. Ciò significa che è semplice creare un nuovo target di test e, il più delle volte, eseguire i test e "funziona". D'altra parte, abbiamo scoperto che in alcuni casi, come l'esecuzione su un dispositivo iOS, era quasi impossibile eseguire i test di OCUnit. L'impostazione delle specifiche Cedar richiede un po 'più di lavoro rispetto ai test OCUnit, dato che hai ottenuto la libreria e il link contro di te (mai un'attività banale in Xcode). Stiamo lavorando per semplificare la configurazione e ogni suggerimento è più che benvenuto.

  • OCUnit esegue i test come parte della build. Ciò significa che non è necessario eseguire un eseguibile per eseguire i test; se qualche test fallisce, la tua build fallisce. Questo rende più semplice il processo di esecuzione dei test e l'output di test va direttamente nella finestra di output della build, il che rende più semplice la visualizzazione. Abbiamo scelto di far convertire le specifiche Cedar in un eseguibile che viene eseguito separatamente per alcuni motivi:

    • Volevamo essere in grado di utilizzare il debugger. Esegui le specifiche Cedar proprio come faresti con qualsiasi altro eseguibile, quindi puoi usare il debugger allo stesso modo.
    • Volevamo una facile registrazione della console nei test. È possibile utilizzare NSLog () nei test OCUnit, ma l'output va nella finestra di compilazione in cui è necessario aprire il passaggio di generazione per poterlo leggere.
    • Volevamo un report di test facile da leggere, sia sulla riga di comando che in Xcode. I risultati di OCUnit appaiono bene nella finestra della build in Xcode, ma la costruzione dalla riga di comando (o come parte di un processo CI) genera un output di test combinato con un sacco e un sacco di altri output di build. Con fasi separate di costruzione ed esecuzione Cedar separa l'output in modo che l'output del test sia facile da trovare. Il runner di prova Cedar predefinito copia lo stile di stampa standard "." per ogni specifica passante, "F" per le specifiche non riuscite, ecc. Cedar ha anche la possibilità di usare oggetti reporter personalizzati, in modo che tu possa avere risultati di output nel modo che preferisci, con un piccolo sforzo.
  • OCUnit è il framework di test unitario ufficiale per Objective C ed è supportato da Apple. Apple ha fondamentalmente risorse illimitate, quindi se vogliono qualcosa fatto sarà fatto. E, dopo tutto, questa è la sandbox di Apple in cui stiamo giocando. Il rovescio della medaglia, tuttavia, è che Apple riceve ogni giorno ordini dell'ordine di bajillion e segnalazioni di bug. Sono straordinariamente bravi a gestirli tutti, ma potrebbero non essere in grado di gestire i problemi segnalati immediatamente o del tutto. Cedar è molto più recente e meno cotto di OCUnit, ma se hai domande o problemi o suggerimenti invia un messaggio alla mailing list di Cedar ([email protected]) e faremo tutto il possibile per aiutarti. Inoltre, non esitare a inserire il codice da Github (github.com/pivotal/cedar) e aggiungere quello che pensi manchi. Rendiamo i nostri framework di test open source per un motivo.

  • Eseguire test OCUnit su dispositivi iOS può essere difficile. Onestamente, non ho provato questo per un po 'di tempo, quindi potrebbe essere diventato più facile, ma l'ultima volta che ho provato semplicemente non riuscivo a ottenere test OCUnit per far funzionare qualsiasi funzionalità di UIKit. Quando abbiamo scritto Cedar ci siamo assicurati di testare il codice dipendente da UIKit sia sul simulatore che sui dispositivi.

Infine, abbiamo scritto Cedar per il test delle unità, il che significa che non è realmente paragonabile a progetti come UISpec. È passato un po 'di tempo da quando ho provato a utilizzare UISpec, ma ho capito che si concentrava principalmente sull'intervento programmatico dell'interfaccia utente su un dispositivo iOS. Abbiamo deciso in particolare di non provare ad avere Cedar per supportare questo tipo di specifiche, dato che Apple stava (al momento) in procinto di annunciare UIAutomation.


Attualmente utilizzo specta per le configurazioni di rspec e il suo partner (come detto sopra) Expecta che ha una tonnellata di fantastiche opzioni di abbinamento.


GHUnit è buono per i test unitari; per i test di integrazione, ho usato UISpec con un certo successo (github fork qui: https://github.com/drync/UISpec ), ma non vedo l'ora di provare iCuke, dal momento che promette di essere un setup leggero, e tu puoi usa i binari per testare la bontà, come RSpec e Cucumber.


Mi piace molto OCDSpec2 ma sono di parte, ho scritto OCDSpec e ho contribuito al secondo.

È molto veloce anche su iOS, in parte perché è costruito da zero piuttosto che essere messo al di sopra di OCUnit. Ha anche una sintassi RSpec / Jasmine.

https://github.com/ericmeyer/ocdspec2


Per lo sviluppo basato su test, mi piace usare GHUnit , è un gioco da ragazzi, e funziona anche per il debug.


Vorrei scegliere iCuke per i test di accettazione e Cedar per i test unitari. UIAutomation è un passo nella giusta direzione per Apple, ma gli strumenti richiedono un supporto migliore per l'integrazione continua; ad esempio, eseguire automaticamente test di UIAutomation con Instruments non è attualmente possibile.





ios-ui-automation