Codice unità client di test delle unità di gestione

Question

Attualmente sto scrivendo un'applicazione client client Java. Quindi voglio implementare due librerie, una per il client e una per il server. La comunicazione server client ha un protocollo molto rigido, che non voglio testare con JUnit.

Come strumento di configurazione im utilizzando Maven e un server Husdon per l'integrazione continua.

In realtà non ho una buona idea su come testare queste librerie client/server.

ho avuto seguenti approcci:

1. Basta scrivere un manichino client per testare il server e scrivere una Dummy Server per testare il Cliente. Svantaggi: Sfortunatamente questo comporterà molti lavori extra. Non potrei essere sicuro al 100% che client e server possano lavorare insieme, perché non sono sicuro che i test siano completamente identici.

2. Scrivere un progetto di prova separato che testa insieme il client e il server.
   Svantaggi: I Test unità non appartengono al Progetto stesso, quindi Hudson non li eseguirà automaticamente. Tutti coloro che modificano qualcosa in una di queste librerie, dovranno eseguire i test manualmente per assicurarsi che tutto sia corretto. Inoltre non riceverò alcun rapporto sulla copertura del codice.

Ci sono approcci migliori per testare codici come quelli? Forse prova un Maven Multi Module Project, o qualcosa del genere.

Spero che qualcuno abbia trovato una buona soluzione per quel problema.

Grazie.

Answer 1

Così alla fine la risoluzione è stato quello di costruire un modulo di progetto multi, con un modulo di prova separata che include il server e il modulo client Grandi opere in Husdon. E ancora meglio nell'IDE di Eclipse. Grazie a Aaron per il suggerimento

Answer 2

pensare a tutto il codice come "trasforma ingresso e uscita": X -> [A] -> Y

X sono i dati che va in, [A] è il trasformatore, Y è l'uscita. Nel tuo caso, si ha questa configurazione:

[Client] -> X -> [Server] -> Y -> [Client] 

Così i test di unità di lavoro in questo modo:

1. Hai bisogno di un test che viene eseguito il codice del client per generare X. Verificare che il codice produca effettivamente X con un assert. X dovrebbe essere un final static String nel codice.

2. Utilizzare la costante X in un secondo test per chiamare il codice server che lo trasforma in Y (un'altra costante).

3. Un terzo test consente di verificare che il codice client in grado di analizzare l'ingresso Y

In questo modo, è possibile mantenere i test indipendenti e ancora fare in modo che le parti più importanti funzionano: L'interfaccia tra i componenti.

Answer 3

È possibile utilizzare qualsiasi framework di oggetti di simulazione per creare oggetti fittizi: provare jmockit.

Answer 4

Il mio suggerimento sarebbe quello di utilizzare due livelli di prova:

1. Per il vostro progetto client/server, includere alcuni beffardo nei vostri test di unità per garantire le interfacce degli oggetti funzionano come previsto.

2. Dopo la generazione, eseguire un test di integrazione più esteso, con l'automazione per installare il client e il server compilati su uno o più sistemi di test. Quindi puoi assicurarti che tutti i dettagli del protocollo siano testati accuratamente. Avere questo progetto di test di integrazione attivato su ogni build di successo del progetto client/server. Puoi usare JUnit per questo e comunque ricevere il rapporto convenzionale di Hudson.

Answer 5

L'ultimo approccio per risolvere questo problema è utilizzando i contenitori Docker. Creare un file di finestra mobile contenente un'immagine di base e tutte le dipendenze necessarie richieste per l'applicazione del server client. Creare un contenitore separato per ogni tipo di nodo del sistema client-server distribuito e testare tutte le interazioni API/client del server entry point utilizzando TestNG o JUnit. La parte migliore di questo approccio è che non stai prendendo in giro nessuna chiamata di servizio. Nella maggior parte dei casi è possibile orchestrare tutte le interazioni client-server end-to-end.

C'è un po 'di curva di apprendimento coinvolti in questo approccio, ma Docker sta diventando molto popolare nella comunità Dev soprattutto per risolvere questo problema.

Ecco un esempio di come è possibile utilizzare finestra mobile client API per tirare le immagini Docker il test JUnit: https://github.com/influxdb/influxdb-java/blob/master/src/test/java/org/influxdb/InfluxDBTest.java