Sto sviluppando un'applicazione Java 6 EE e sto testando il mio codice jsp con un altro con una versione di prova delle chiamate di funzione e del codice utilizzato in quello originale, ma sembra sciolto e poco pratico. C'è un buon modo per eseguire questo tipo di test?
Risposte:
Se non hai letto su MVC (controller vista modello), fallo. Non dovresti avere il codice in un JSP, basta visualizzare. Inserire il codice in JSP è molto del 1900.
Scherzi a parte, se non ci sono codici nel JSP, non stai testando il JSP. Stai testando l'azione / flusso. Quindi è possibile utilizzare HttpUnit o Selenium . La grande differenza è che il selenio esegue il test da un browser reale.
Non penso che ci sia un buon modo per testare i JSP, principalmente perché sono stati sviluppati prima che i test unitari diventassero al centro dello sviluppo.
Robert Martin ha scritto diversi anni fa un articolo sull'hacking del compilatore JSP in modo da poter dirigere test unitari non basati su container. La sua idea è stata buona, ma è stata rotta con la prossima versione principale di TomCat. C'è troppa magia in corso.
Non sono d'accordo con l'idea "solo non aggiungere il codice e non sarà necessario testarlo". Ovviamente non dovresti inserire codice nel JSP. Tuttavia, un'interfaccia utente complessa avrà spesso una logica di visualizzazione che potrebbe essere proficuamente testata in 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 ponderato: la logica per decidere se mostriamo il menu di amministrazione non è nella vista. Tuttavia, se ci fosse un modo semplice per testare l'unità JSP, allora potremmo scrivere un test per mostrare che il comportamento che vogliamo effettivamente appare, e ci proteggerebbe da una modifica alla pagina che ha reso accidentalmente visibile il menu di amministrazione quando non dovrebbe essere.
Esiste un programma (utilizzato da qualsiasi server delle applicazioni in uso) che compila un file .jsp in un file .java. Ad esempio, la versione sun / oracle jspc .
Una volta che hai il .java che verrebbe prodotto dalla traduzione .jsp (potresti anche considerare di usarlo come parte del processo di compilazione - precompilare il jsp per migliorare le prestazioni al primo colpo), puoi quindi eseguire test contro di esso deridendo la richiesta e verificando la risposta è quello che ti aspetti.
(modifica con esempio :)
Il metodo chiave per questo è il _jspService(HttpServletRequest, HttpServletResponse)metodo.
Un banale ciao mondo 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 in una directory denominata 'webapp' e anche una directory 'out') Quando compilato con il comando jspc -v -d out -compile -uriroot webapp/ test.jspinserisce 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 sia chiamato con write o print e che il contenuto della chiamata sia quello che ci si aspetta che sia.
Detto questo, in un mondo ideale, non si dovrebbe avere alcuna logica all'interno del jsp - tale logica sarebbe o nel controller o nei tagli che sono testati con altre tecniche.
Puoi anche prendere in considerazione l'utilizzo di un framework di test unità HTTP come HTTPUnit | http://httpunit.sourceforge.net/ .
Un altro punto importante è quello di separare bene le preoccupazioni della tua applicazione.
Ad esempio, usando tecniche come TDD (http://en.wikipedia.org/wiki/Test-driven_development), progetterai i tipi per la testabilità.
I tipi consumati all'interno di JSP saranno testati in test unitari specifici. Se ciò non è possibile, è necessario simulare l' interazione utente -> browser (di nuovo, HTTPUnit o strumento simile).