Gestione del codice: unit test con source o separato?

Question

Gestione del codice: unit test con source o separato?

#1 da (3 voti)
#2 da (0 voti)

6

La pratica standard nel mondo Objective C è stata quella di seguire quella prevista nel mondo Java quando si tratta di gestione del codice. Ad esempio, il codice sorgente dell'applicazione va in una directory e il codice di test dell'unità viene inserito in un altro.

Ho sempre trovato questo un po 'di dolore. Soprattutto perché tendo ad organizzare XCode allo stesso modo. I problemi che mi infastidiscono sono:

Dover mantenere sincronizzati tutti i vari gruppi in termini di nomi, ecc.
Non è facile riuscire a vedere quali classi hanno classi di test corrispondenti.
Devo scorrere su e giù tra le gerarchie tutto il tempo mentre rimbalzo tra test e sorgente.

Quindi stavo pensando - Cosa succede se inserisco il codice di test accanto al codice sorgente? Nella stessa directory. E in XCode posso quindi avere il codice di test seduto con l'origine e individuare e vedere facilmente le classi corrispondenti.

Qualcuno ha provato questo? È fattibile? O c'è un'altra soluzione?

testing xcode

posta drekka 24.07.2015 - 16:03

fonte

2 risposte

Leggi altre domande sui tag testing xcode

Devo scaricare script da un CDN o raggruppare tutto in uno script? Come dovrei progettare classi di dati serializzabili JSON per rispettare i futuri campi @NonNull

score 3 · Answer 1

Come dice sempre lo zio Bob, i tuoi test non devono essere accoppiati alla struttura della tua applicazione ( ottimo blog che parla di questo argomento ).

Facendo ciò che stai suggerendo sembra che tu possa incorrere in problemi con la distribuzione o altri aspetti dello sviluppo ... Ma il problema più grande che vedo è che sarai tentato di (se non forzato) di accoppiare il tuo test- suite per la tua struttura applicativa.

Non ti consiglio di permetterti di affrontare il mondo dei mal di testa futuri (da qualcosa di semplice come un piccolo refactoring) che viene con questa decisione.

score 0 · Answer 2

Ho provato questo e non lo consiglierei ... se hai solo un po 'di classi per pacchetto potrebbe sembrare carino ma, immaginiamo un pacchetto con 20 classi di produzione ... ci saranno anche 20 file di test posizionati lì? Per me sarà troppo ...

Inoltre, forse con quella struttura che non segue la convenzione standard, è necessario configurare manualmente alcune delle funzionalità del tuo strumento di compilazione / pipeline CI con una configurazione specifica e questo, a mio parere, non promuove l'interoperabilità

Per quanto riguarda i dolori che hai citato, penso che con un IDE moderno possano essere risolti:

Dover mantenere sincronizzati tutti i vari gruppi in termini di nomi, ecc.

Questo può essere risolto utilizzando le funzionalità incluse per generare automaticamente i test. Se poi stai cambiando il nome della classe, puoi cambiarlo con l'IDE che cambierà il nome stesso e tutti i suoi riferimenti, incluso il nome del test.

Non è facile riuscire a vedere quali classi hanno classi di test corrispondenti.

Ancora una volta l'IDE moderno ha una funzionalità per controllare facilmente quali origini di test puntano alla tua classe di produzione, anche se ci sono molti test diffusi attraverso diversi file

Devo scorrere su e giù tra le gerarchie tutto il tempo mentre rimbalzo tra test e sorgente.

Lo stesso qui, se fai clic con il tasto destro in qualsiasi classe avrai l'opzione di andare ai test e verrà fornito anche un pulsante per tornare indietro.

Tutte queste belle funzionalità fornite dall'IDE saranno soggette alla configurazione manuale se segui l'approccio menzionato nella tua domanda.