Sto sviluppando un'applicazione Java 6 EE e sto testando il mio codice jsp con un altro con una versione di prova della funzione chiamate e codice usato in quella originale, ma sembra allentato e poco pratico. Esiste un buon modo per eseguire questo tipo di test?
Se non hai letto su MVC (model view controller), fallo. Non dovresti avere il codice in un JSP, solo display. Mettere il codice in JSP è molto 1900.
Seriamente, se non ci sono codici nel JSP, non stai testando il JSP. Stai testando l'azione / il flusso. Quindi puoi utilizzare HttpUnit o Selenium . La grande differenza è che il Selenium esegue test da un vero browser.
Non penso che ci sia un buon modo per testare i JSP, principalmente perché sono stati sviluppati prima che i test unitari diventassero un focus di sviluppo.
Robert Martin ha scritto un articolo diversi anni fa sull'hacking del compilatore JSP in modo da poter effettuare test unitari non basati su container. La sua idea è stata buona, ma è stata interrotta con la prossima versione principale di TomCat. C'è solo troppa magia in corso.
Non sono d'accordo con l'idea "non aggiungere codice e non dovrai testarlo". OVVIAMENTE non dovresti inserire il codice nel JSP. Ciononostante, un'interfaccia utente complessa avrà spesso una logica di visualizzazione che potrebbe essere proficuamente testata da un'unità.
Considera questo esempio:
<c:choose>
<c:when test="${mydto.showAdminMenu}">
The admin menu....
</c:when>
<c:otherwise>
Something completely different
</c:otherwise>
</c:choose>
Questo codice è già ben calcolato: la logica per decidere se mostrare il menu di amministrazione non è nella vista. Tuttavia, se esistesse un modo semplice per testare le JSP unitarie, allora potremmo scrivere un test per dimostrare che il comportamento che vogliamo effettivamente appare e ci proteggerebbe da una modifica alla pagina che accidentalmente ha reso visibile il menu di amministrazione quando non avrebbe dovuto essere.
Esiste un programma (utilizzato da qualsiasi server di applicazioni che si sta utilizzando) che compila un file .jsp in un file .java. Ad esempio, la versione sun / oracle jspc .
Una volta che hai il .java che sarebbe stato prodotto dalla traduzione .jsp (potresti anche voler considerare l'utilizzo di questo come parte del processo di compilazione - precompilare il jsp per i miglioramenti delle prestazioni al primo colpo), puoi quindi eseguire prova contro di esso prendendo in giro la richiesta e verificando la risposta è quello che ti aspetti.
(modifica con esempio:)
Il metodo chiave per questo è il metodo _jspService(HttpServletRequest, HttpServletResponse) .
Un banale mondo ciao jsp:
<html>
<head>
<title>Hello world</title>
</head>
<body>
<h1>Hello world</h1>
Today is: <%= new java.util.Date().toString() %>
</body>
</html>
(test.jsp situato all'interno di una directory chiamata 'webapp' e anche una directory 'out') Quando compilato con il comando jspc -v -d out -compile -uriroot webapp/ test.jsp inserisce in una directory out un file chiamato test_jsp.java . Questo file ha al suo interno (insieme a un bel po 'di altre impostazioni di configurazione):
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {
PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;
PageContext _jspx_page_context = null;
try {
response.setContentType("text/html");
pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
_jspx_page_context = pageContext;
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
out.write("<html>\n\t<head>\n\t\t<title>Hello world</title>\n\t</head>\n\t<body>\n\t
\t<h1>Hello world</h1>\n\t\tToday is: ");
out.print( new java.util.Date().toString() );
out.write("\n\t</body>\n</html>\n\n");
} catch (Throwable t) {
if (!(t instanceof SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
try { out.clearBuffer(); } catch (java.io.IOException e) {}
if (_jspx_page_context != null) _jspx_page_context.handlePageException(t);
}
} finally {
_jspxFactory.releasePageContext(_jspx_page_context);
}
}
}
A questo punto, è un controllo per assicurarsi che JspWriter venga chiamato con scrittura o stampa e il contenuto della chiamata sia quello che ti aspetti che sia.
Tutto ciò che ho detto, in un mondo ideale, non si dovrebbe avere alcuna logica all'interno del jsp - tale logica potrebbe essere nel controller o nei tagli che vengono testati con altre tecniche.
Puoi anche prendere in considerazione l'utilizzo di un framework di test dell'unità HTTP come HTTPUnit | link .
Un altro punto importante è quello di separare le preoccupazioni della tua applicazione.
es. utilizzando tecniche come TDD (http://en.wikipedia.org/wiki/Test-driven_development), dovrai progettare i tipi per testabilità.
I tipi consumati all'interno di JSP verranno testati in test unitari specifici. Se ciò non è possibile, devi simulare utente - > interazione del browser (ancora, HTTPUnit o strumento simile).
Leggi altre domande sui tag testing unit-testing programming-practices java-ee