Si tratta praticamente di una evoluzione di questa fixture che consente di fare alcune verifiche basate su xpath rispetto al contenuto di una pagina web, ovvero verificare che un certo nodo, individuato via espressione xpath, sulla pagina indicata da una certa url esista o meno, che abbia un certo valore, oppure che il numero di nodi che "matchano" l'espressione sia quello che ci si aspetta.
A questo ho aggiunto le seguenti caratteristiche:
- poter accedere a pagine che richiedono autenticazione (basic o, in alcuni casi, form)
- poter lavorare anche su pagine che non sono ben formate come xml, usando jTidy come preprocessor
- gestire i cookies così potendo gestire anche la sessione di navigazione (se basata su cookie)
- gestire eventuale submission di parametri via post o get.
- poter generare automaticamente un test che va a buon fine rispetto ad un esempio statico.
In teoria dovrebbe essere sufficiente per poter fare dei chiari test di accettazione per applicazioni web, almeno se si tratta di testare solamente cose "server side" (niente javascript/ajax quindi).
Per esempio: il customer si dice soddisfatto che l'applicazione renderizzerà una pagina in modo conforme ad un certo esempio fornito come pagina statica. A quel punto la pagina statica viene "processata" da xml2xpath, e viene creato il relativo test che ha successo quando la pagina viene "deployata".
Supponiamo che nella pagina vi sia una tabella, che dovrà poi contenere dati dinamici.
Il customer vorrà magari che "in quella tabella poi dovranno essere presenti i dati che verranno inseriti in una certa form".
Allora si modifica subito l'espressione xpath che verifica i dati in tabella, e si fa in modo che il test sia esteso in modo da incluere anche l'azione di "inserire un certo dato, e poi andare nella pagina dell'elenco ed aspettarsi di trovare quel dato".
La cosa descritta adesso è più o meno una user story e l'idea è di scrivere un test che la "descrive", e ne verifica anche la corretta implementazione.
Un po' più in dettaglio se la pagina statica pensata all'inizio è del tipo:
<html>
<head/>
<body>
<table>
<tr>
<td>entry1</td>
</tr>
<tr>
<td>entry2</td>
</tr>
<tr>
<td>entry3</td>
</tr>
</table>
</body>
</html>
allora lo stylesheet xml2xpath genera il seguente pezzo di tabella di test:
| Value | /html/body/table/tr/td | entry1 |
| Value | /html/body/table/tr[2]/td | entry2 |
| Value | /html/body/table/tr[3]/td | entry3 |
a questo punto, se si progetta che l'azione di inserimento di questi dati dovrà essere data da una certa jsp che si chiamerà submitaction.jsp, con un parametro entryname, allora, prendendo un po' spunto dal test precedente, l'intera storia "sottometti il dato entryX e poi verifica che
visualizzando la tabella, esso sia presente", è un po' come segue":
...
|newUrlPost|http://myserver/submitaction.jsp|
|NameValuePair|entryname|entryX|
|newUrlGet|http://myserver/visualize.jsp |
|AValue|/html/body/table/tr[*]/td | entryX |
Ovviamente poi il test resta lì utile anche a verificare non solo quando l'implementazioe è corretta, ma anche che continui a rimanere corretta.
Nessun commento:
Posta un commento