It continues the approach introduced by this fixture that allows to check xpath respect to the content of a web page. Test can check if some nodes identified by xpath are present or not, if they contain some expected value, and how many nodes match the expression.
I added the following features:
- test pages that requires authenntication (basic o, in some cases, form)
- test pages not well formed, using jTidy as preprocessor
- manage cookies and so cokies based session
- manage post and get based parameters subscription.
- ability to generate test from statical pages.
This approach allows acceptance tests for web application only for server side plain web application (no javascript/ajax)
A sketch of the process of a "costumer test driven development" using this approach could be described as follows: you have a statical html, and you are going to modify some part of it to let it became dynamical (by some server side logic).
Creating the page is not viable by "test first".
We can just have for free a test that has success if applied to the page.
After we have the test ready, then we can modify, or reuse, it according to some user story that the page is involved to.
In this case we have a test first.
For example, suppose that we have the prototipe of the page, that contains a table.
The tabloe is the part that must be dynamical.
The customer says that "in the table there will be some data previously submitted by a form provided in another page".
To go a little bit deeper through this concept. The statical page could be something like the following:
<html>
<head/>
<body>
<table>
<tr>
<td>entry1</td>
</tr>
<tr>
<td>entry2</td>
</tr>
<tr>
<td>entry3</td>
</tr>
</table>
</body>
</html>
applying a stylesheet that generates the test from the page, you get the following test:
...
| Value | /html/body/table/tr/td | entry1 |
| Value | /html/body/table/tr[2]/td | entry2 |
| Value | /html/body/table/tr[3]/td | entry3 |
You can start coding creating a jsp that renders the page in the same way, where the data will be not hard coded. It will be retriven from a db.
The customer probabily doesn't care about db, or any persistency stuffs. He just asks that "the user will submit some data on that form, and the data will appear in the table".
(Thus such kind of test dos not involve business logic tier.)
A test based description of that story, can be as follows:
...
|newUrlPost|http://myserver/submitaction.jsp|
|NameValuePair|entryname|entryX|
|newUrlGet|http://myserver/visualize.jsp |
|AValue|/html/body/table/tr[*]/td | entryX |
that means somethig like "the submitaction.jsp you are going to implement, will expect a parameter named entryname. If the sumitted parameter is entryX, then, if you navigate to the page visualize.jsp, the entryX should be present in any part of the table"
This test describes what you will get, and you can start coding the submitaction.jsp and visualize.jsp until the tests doesn't fail.
To conclude, we can call this stuff an approach like:
. design the statical page,
. create test that matches if applied to the page,
. modify/reuse/rearrange the test according to a user story where the page is involved,
. code until the test doesn't fail
No comments:
Post a Comment