tl; dr
In Pivotal abbiamo scritto Cedar perché usiamo e amiamo Rspec nei nostri progetti Ruby. Cedar non è destinato a sostituire o competere con OCUnit; ha lo scopo di portare la possibilità di test in stile BDD su Objective C, proprio come Rspec ha aperto la strada ai 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 ovviare ad 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 nelle build degli elementi della configurazione e ottenere utili output di testo dei risultati dei test. Queste cose potrebbero esserti più o meno utili.
Risposta lunga
Decidere tra due framework di test come Cedar e OCUnit (ad 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 I test unitari in stile unità sono in circolazione da molto più tempo dei 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 ampia adozione (tra gli sviluppatori che scrivono unit test); in quasi tutte le lingue in cui potresti considerare di scrivere il codice è disponibile un framework in stile xUnit.
I framework in stile BDD tendono ad avere due differenze principali rispetto allo stile xUnit: come strutturi il test (o le specifiche) e la sintassi per scrivere le tue asserzioni. Per me, la differenza strutturale è il principale fattore di differenziazione. I test xUnit sono monodimensionali, con un metodo setUp per tutti i test in una determinata classe di test. Le classi che testiamo, tuttavia, non sono monodimensionali; spesso abbiamo bisogno di testare le azioni in diversi contesti, potenzialmente contrastanti. Ad esempio, considera una semplice classe ShoppingCart, con un metodo addItem: (ai fini di questa risposta userò la sintassi dell'Obiettivo 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 sconto; può differire se l'articolo specificato può ' essere spedito con il metodo di spedizione selezionato; ecc. Poiché queste possibili condizioni si intersecano tra loro, 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 queste condizioni individualmente, cosa che trovo semplifica il processo di copertura di tutti i casi, nonché la ricerca, la modifica o l'aggiunta di condizioni individuali. Ad esempio, usando la sintassi di Cedar, il metodo sopra sarebbe simile a questo: 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 queste condizioni individualmente, cosa che trovo semplifica il processo di copertura di tutti i casi, nonché la ricerca, la modifica o l'aggiunta di condizioni individuali. Ad esempio, usando la sintassi di Cedar, il metodo sopra sarebbe simile a questo: 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 queste condizioni individualmente, cosa che trovo semplifica il processo di copertura di tutti i casi, nonché la ricerca, la modifica o l'aggiunta di 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 che contengono gli stessi insiemi di asserzioni, che puoi ASCIUGARE usando contesti di esempio condivisi.
La seconda differenza principale tra framework in stile BDD e framework in stile xUnit, sintassi di asserzione (o "matcher"), rende semplicemente più piacevole lo stile delle specifiche; ad alcune persone piace davvero, ad altri no.
Ciò porta alla questione della facilità d'uso. In questo caso, ogni framework ha i suoi pro e contro:
OCUnit è in circolazione da molto più tempo di Cedar ed è integrato direttamente in Xcode. Ciò significa che è semplice creare un nuovo target di test e, la maggior parte delle volte, far funzionare i test "funziona". D'altra parte, abbiamo scoperto che in alcuni casi, come l'esecuzione su un dispositivo iOS, far funzionare i test OCUnit era pressoché impossibile. L'impostazione delle specifiche Cedar richiede un po 'più di lavoro rispetto ai test OCUnit, dal momento che hai la libreria e il collegamento da solo (mai un'attività banale in Xcode). Stiamo lavorando per semplificare l'installazione e qualsiasi 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. Ciò rende il processo di esecuzione dei test un passo più semplice e l'output del test va direttamente nella finestra di output della build che lo rende facile da vedere. Abbiamo scelto di includere le specifiche Cedar in un eseguibile che puoi eseguire 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 utilizzare il debugger allo stesso modo.
- Volevamo una facile registrazione della console nei test. È possibile utilizzare NSLog () nei test OCUnit, ma l'output passa alla finestra di compilazione in cui è necessario aprire il passaggio di compilazione per poterlo leggere.
- Volevamo leggere facilmente i rapporti sui test, sia nella riga di comando che in Xcode. I risultati di OCUnit appaiono bene nella finestra di compilazione in Xcode, ma la compilazione dalla riga di comando (o come parte di un processo CI) si traduce in un output di test mescolato a molti altri output di compilazione. Con fasi di costruzione ed esecuzione separate Cedar separa l'output in modo che l'output del test sia facile da trovare. Il runner di prova Cedar predefinito copia lo stile standard di stampa "." per ogni specifica che passa, "F" per specifiche non riuscite, ecc. Cedar ha anche la possibilità di utilizzare oggetti reporter personalizzati, in modo da poter ottenere i risultati di output come preferisci, con un piccolo sforzo.
OCUnit è il framework ufficiale di unit test per Objective C ed è supportato da Apple. Apple ha sostanzialmente risorse illimitate, quindi se vogliono qualcosa fatto, lo farà. E, dopo tutto, questo è il sandbox di Apple in cui stiamo giocando. Il rovescio della medaglia, tuttavia, è che Apple riceve nell'ordine di un bajillion richieste di supporto e segnalazioni di bug ogni giorno. Sono straordinariamente bravi a gestirli tutti, ma potrebbero non essere in grado di gestire i problemi segnalati immediatamente o affatto. Cedar è molto più nuovo e meno cotto di OCUnit, ma se hai domande, problemi o suggerimenti invia un messaggio alla mailing list di Cedar (cedar-discuss@googlegroups.com) e faremo il possibile per aiutarti. Inoltre, sentiti libero di rovesciare il codice da Github (github.com/pivotal/cedar) e aggiungere tutto ciò che pensi manchi.
L'esecuzione dei test OCUnit su dispositivi iOS può essere difficile. Onestamente, non ho provato questo da un po 'di tempo, quindi potrebbe essere diventato più facile, ma l'ultima volta che ho provato non sono riuscito a far funzionare i test OCUnit per far funzionare qualsiasi funzionalità UIKit. Quando abbiamo scritto Cedar ci siamo assicurati di poter testare il codice dipendente da UIKit sia sul simulatore che sui dispositivi.
Infine, abbiamo scritto Cedar per unit test, il che significa che non è davvero paragonabile a progetti come UISpec. È passato un po 'di tempo da quando ho provato a usare UISpec, ma ho capito che si concentrava principalmente sulla guida programmatica dell'interfaccia utente su un dispositivo iOS. In particolare, abbiamo deciso di non provare a fare in modo che Cedar supporti questo tipo di specifiche, poiché Apple (all'epoca) stava per annunciare UIAutomation.