Procedure consigliate su come includere test unitari in una libreria

Question

Sto lavorando su una libreria di codici generale per ActionScript 3.0 chiamata as3lib che include diverse estensioni all'API principale e alcune funzioni utili.Ho scritto diversi test unitari (utilizzando FlexUnit) per assicurarmi che tutto funzioni correttamente.

Qual è il modo migliore per organizzare questi test in biblioteca? Attualmente ho tutto il codice inserito src/ e i miei test in test/ ma ho impostato un progetto Flex secondario per eseguire i test unitari.Inoltre aggiungo e rimuovo manualmente i file di test dalla libreria quando desidero eseguire i test.

Quello che sto facendo non mi sembra giusto.C'è un modo migliore?Preferibilmente uno in cui la libreria compilata non include i file di test ma non ho bisogno di due progetti separati per testarli.

Answer 1

Il modo in cui abbiamo fatto queste cose a mia azienda è che in realtà includiamo entrambi sotto la directory di origine, e poi abbiamo due file MXML che utilizziamo. Uno è la suite di test, che comprende tutti i collegamenti appropriati alle classi unità-test, l'altro è l'applicazione principale. Abbiamo anche avere due strutture pacchetto all'interno della cartella src: una struttura del pacchetto com .., e un altro tests.com ... Assicurarsi che tutti il codice sorgente per i test unitari sono SEMPRE nella confezione test - in questo modo è possibile utilizzare un solo SVN ignorare, e si può anche fare in modo che i test non creano relazioni di dipendenza e hard-coded con altri progetti

.

Ci sono due modi che usiamo per garantire che i file di origine test.com non sono inclusi. Il sistema di compilazione automatica fa riferimento solo l'applicazione principale, e dal momento che solo le importazioni dalla com., Mxmlc.exe includerà solo i file per l'applicazione principale. Quando si costruisce a livello locale, all'interno di Eclipse, è possibile controllare come le cose costruire facendo clic sulla piccola freccia accanto a debug e scorrere fino a "Organizza preferiti." Quando si fa clic su "Aggiungi", si dovrebbe essere in grado di selezionare tutti i file .mxml livello principale, che fanno riferimento alla classe di applicazione. Assicurarsi di aggiungere l'applicazione di base e il nuovo file applicazione di test unità. Quando si fa clic su "OK", la freccia consente ora di eseguire il debug sia come l'applicazione principale, o il vostro framework di unit test.

Per inciso, usiamo anche FlexUnit come il nostro framework di test. Mi piace.

Answer 2

L'ho fatto simile al modo in cui si sta descrivendo in passato, ma sembra che il genere di cose in cui SpringAS potrebbe venire in piuttosto comodo per l'aggiunta in modo dinamico e rimuoverli dalla configurazione. Hai provato a guardare in che?

Answer 3

Abbiamo src e test directory separate a livello alto nelle nostre biblioteche. Le nostre applicazioni sono wrapper molto sottile intorno progetti di libreria, quindi non hanno bisogno di alcun test. Abbiamo anche un progetto di applicazione FlexUnit, per eseguire i test da FlexBuilder.

Usiamo Maven per il nostro sistema di compilazione principale, e il plugin Sonatype Flex esegue tutti i nostri test di unità durante la costruzione, anche sul nostro server Continuum basato su Linux. default Maven guardare per le prove in una directory 'test', che era una buona giustificazione per la raccolta quella posizione.

Answer 4

Qui andrò controcorrente e suggerirò di impostare un progetto completamente diverso per i tuoi test.Credo che generalmente non abbia molta importanza dove metti i test, purché siano coerenti e in qualche modo gestibili.Tuttavia, per me ci sono tre ragioni convincenti per avere un progetto separato per i test:

1. Separazione degli interessi.Innanzitutto, la tua libreria ha uno scopo, i test ne hanno un altro.Sebbene i test abbiano bisogno della libreria per funzionare, la libreria non ha alcuna utilità reale per i test. Nota che non dico che i test siano inutili, tutt'altro.I test servono a verificare lo stato della libreria, ma in un ambiente di produzione i test non hanno alcuno scopo.

2. Meno voluminosi, file più piccoli.I test non sono sempre banali.Ma anche se lo fossero tutti, continuerebbero a utilizzare lo spazio su disco.Poiché i test non vengono comunque utilizzati in un ambiente di produzione, ciò è inutile.Inoltre, separare i test in un nuovo progetto rende la struttura del file molto più pulita.

3. Gli ambienti CI sono generalmente più puliti da configurare quando i test non sono disponibili.

Sebbene sia certamente possibile risolvere almeno il secondo problema con le direttive del compilatore, è un lavoro inutile quando è molto più semplice separare i due.Anche testare una libreria o un'applicazione che potrebbe richiedere l'utilizzo dello stesso spazio dei nomi (classi interne qualcuno?) non è un problema, poiché il tuo progetto di test potrebbe rispecchiare gli spazi dei nomi.Ovviamente questo rende necessario che non vi siano collisioni di nomi nei namespace, ma è banale.

In termini di supporto di Flash Builder è fantastico separare le cose in due progetti.Tutto quello che devi fare per creare un nuovo test è fare clic con il pulsante destro del mouse sulla classe che desideri testare, chiedere di creare un nuovo test e assicurarti di scegliere il progetto di test anziché quello corrente nella finestra di dialogo che si apre.Questo è davvero il motivo principale per cui io e i membri del mio team abbiamo avuto difficoltà a giustificare la scrittura dei test quando siamo entrati in TDD, troppe spese generali solo per iniziare.Con lo stato attuale dell'IDE, è ridicolmente semplice e utile.

Come con qualsiasi tecnica, tuttavia, ci sono degli avvertimenti.Per prima cosa, non è ovvio che i test siano in un progetto diverso a meno che non sia documentato.Avere i test nello stesso progetto risolve efficacemente questo problema.D'altra parte, questo problema può essere facilmente risolto configurando Maven o altri strumenti di gestione delle dipendenze che potresti avere nel tuo ambiente.Un altro problema è che se nel progetto di test è presente una struttura di pacchetto che rispecchia quella della libreria o dell'applicazione, è necessario un sovraccarico di manutenzione per sincronizzare tali strutture.Sebbene non sia un problema enorme e risolvibile abbastanza facilmente utilizzando lo scripting, vale comunque la pena menzionarlo.

Comunque, è così che faccio.