Di Unit test di servlet [chiuso]

Question

Ho un sacco di servlet in esecuzione sotto il Tomcat servlet container.Vorrei separare il codice di test dal codice di produzione, così ho pensato di utilizzare un framework di test.JUnit è ben integrato in Eclipse, ma non sono riuscito a farlo funzionare servlets utilizzando un server Tomcat in esecuzione.Si potrebbe si prega di raccomandare un test di unit quadro che sostiene il test Tomcat servlet?Eclipse integrazione è bello, ma non è necessario.

Answer 1

Check out ServletUnit, che è parte di HttpUnit.In sintesi, ServletUnit fornisce una libreria di simulazioni e di utilità che è possibile utilizzare ordinario test JUnit per deridere un servlet container e altre servlet-oggetti correlati come oggetti request e response.Il link qui sopra contiene esempi.

Answer 2

Il Framework Spring è bello pronto e oggetti fittizi per diverse classi di Servlet API:

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/mock/web/package-summary.html

Answer 3

Va bene.Ignorando la 'tomcat' di bit e codifica per il servlet, la vostra scommessa migliore è quello di creare simulazioni per la risposta e la richiesta di oggetti, e allora dillo che ci si aspetta di fuori di esso.

Così, per una standard vuoto doPost, e l'utilizzo di EasyMock, avrai

public void testPost() {
   mockRequest = createMock(HttpServletRequest.class);
   mockResponse = createMock(HttpServletResponse.class);
   replay(mockRequest, mockResponse);
   myServlet.doPost(mockRequest, mockResponse);
   verify(mockRequest, mockResponse);
}

Poi iniziare ad aggiungere il codice per il doPost.La deride avrà esito negativo perché non hanno aspettative, e quindi è possibile impostare le aspettative da lì.

Si noti che se si desidera utilizzare EasyMock con le classi, dovrete utilizzare il EasyMock classe extension library.Ma ti funzionano allo stesso modo, da allora in poi.

Answer 4

Separare le parti di codice che si occupano di richieste HTTP e risposta con i pezzi che fanno la logica di business o di data-base per la manipolazione.Nella maggior parte dei casi questo produce architetture three tier, con un livello dati (per il data-base/persistenza), servizio-layer (per la logica di business) e una presentazione-livello (per le richieste HTTP e le risposte).

1. È possibile unit test i primi due strati, senza alcun servlet roba a tutti;sarà più facile di testare in questo modo.
2. È possibile verificare il livello di presentazione, come altri suggeriscono di, utilizzando mock HTTP oggetti request e response.
3. Infine, se si sente che è davvero necessario, è possibile effettuare i test di integrazione utilizzando un troppo come HtmlUnit o JWebUnit .

Answer 5

Per "container" di test, date un'occhiata al Cactus

Se si vuole essere in grado di eseguire il test senza l'esecuzione di un contenitore in cui è possibile simulare i suoi componenti con il proprio mockobjects (ad es.con EasyMock), o si potrebbe provare MockRunner che ha "pre-definito" Stub per il test servlet, jdbc-connessioni etc.

Answer 6

Aggiornamento Febbraio 2018: OpenBrace Limited ha chiuso, e la sua ObMimic prodotto non è più supportato.

Se si desidera che una nuova alternativa per ServletUnit per JUnit test di Servlet, si potrebbe trovare mia azienda ObMimic biblioteca utile.È disponibile gratuitamente dal sito web download pagina.

Come con ServletUnit, esso fornisce una libreria di classi che è possibile utilizzare in una normale JUnit o TestNG al di fuori di qualsiasi servlet container per simulare la Servlet API.

La sua Servlet API oggetti non hanno alcun argomento, costruttori, sono completamente configurabile e modificabile per tutte le Servlet API di dati e impostazioni, e di fornire una simulazione completa di tutti il comportamento specificato dal Servlet API javadoc.Per aiutare con i test c'è il supporto per la registrazione delle Servlet API chiamate, controllo su ogni contenitore-dipendente comportamento, controlli per ogni ambiguo chiamate (es.dove la Servlet API comportamento non è completamente definito), e in memoria JNDI di simulazione per qualsiasi servlet codice che si basa su JNDI ricerche.

Per tutti i dettagli, codice di esempio, "come" guide, Javadoc, ecc, vedere il sito web.