1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
$Id: README,v 1.4 2004/06/19 12:13:57 rurban Exp $
TODO: certain blocks are repeated over and over. For example, editing
a page is always the same set of links to follow, but this info is
duplicated across all test scripts. There should be a way of
abstracting this info. Macros perhaps.
System requirements for the test suite for PhpWiki:
Sun's Java SDK http://java.sun.com/j2se/
httpunit http://httpunit.sf.net
Ant http://jakarta.apache.org/builds/jakarta-ant/release/
jtidy http://sourceforge.net/project/showfiles.php?group_id=13153
(actually httpunit needs jtidy, not this test system per se)
This was tested against Ant version 1.4.1 and httpunit 1.3.
---
(This is just a set of entries from my work log when I was at Capital
Thinking. It was then copy/pasted into their Wiki (they used PyWiki)
as a little tutorial on how to use it. All of the basic information is
here. It was tailor made for their system, so some reworking is still
needed to make it work with PhpWiki; also I didn't quite grok unit
testing as implemented by httpunit at the time. I suppose we'd also be
better off using the PHP version of httpunit as well, though it was
still beta when I last looked at it.
Capital Thinking uses ATG Dynamo on Solaris, so all of our work was in
Java and Perl, in case you were wondering why these were chosen).
How to make a single test
* write the script
* generate the java file
* compile it, run it
How to make a test suite:
* write the script
* run makemakebuild.pl
* run ant
--------------
Short Tutorial
The GuiTester is a small simple system to test the GUI of the BlueWire system.
As a programmer you have to do these steps:
1. Write a little input script. Let's call it MyTest.inputs.
2. Create a Java source file with your input script, with a Perl script called maketest.pl. Run this command: '''maketest.pl MyTest.inputs'''. This will create a file called MyTest.java.
3. Compile your file: '''javac MyTest.java'''
4. Run your test: '''java MyTest'''
That's the short form for writing your own single test. You can accumulate tests in a single directory, and via the magical tools "make" and Ant, run a whole set of tests.
1. Write one or more input scripts.
1. run '''makemakebuild.pl'''. This script gets the names of all .input files in the current directory and generates a Makefile and a build.xml file.
1. Run ant with no arguments, i.e. just type "ant" and hit return.
That's all. All the Java files will be generated for you, compiled, and ran against BlueWire.
-----------------
A Longer Tutorial
An input script, which follows the naming convention ClassName.inputs,
consists of a set of little statement blocks. Here is a sample which
handles logging in to the system:
# start script
# get the starting page
type: starting_page
start_url: http://127.0.0.1:8850/jpmorgan/index.jhtml
go
# log in
type: fill_and_submit_form
form_num: 0
submitbutton_num: 0
setparam: "/jpmorgan/dbbeans/CTAuthentication.bean.username", "jpmorganuser"
setparam: "/jpmorgan/dbbeans/CTAuthentication.bean.password", "jpmorganuser"
assert_url: active_deals
go
# end script
(If you use Emacs you can get some nice color highlighting with:
M-x font-lock-mode RET
M-x sh-mode RET)
First, each block starts with a type: command and ends with "go":
type: starting_page
start_url: http://127.0.0.1:8850/jpmorgan/index.jhtml
go
This tells the code generator the action we're taking ("type:") is
going to the starting page, and "start_url:" has the URL to go to.
The second block will fill in and submit the form:
type: fill_and_submit_form
form_num: 0
submitbutton_num: 0
setparam: "/jpmorgan/dbbeans/CTAuthentication.bean.username", "jpmorganuser"
setparam: "/jpmorgan/dbbeans/CTAuthentication.bean.password", "jpmorganuser"
assert_url: active_deals
go
Here form_num is the form number in the page; that is, in
Javascript-land, each form in the page has a number starting at
zero. Likewise all submit buttons have a number (per form) starting at
zero. "setparam" gives the name of the form field and the value for
that field. Later we will see you can use names for the forms and
submit buttons, if available.
Here's a list of the keywords in the little scripting language:
assert_field:
assert_text:
assert_title:
assert_url:
follow_image_link:
follow_link:
form_name:
form_num:
go
setparam:
start_url:
submitbutton_name:
submitbutton_num:
type:
#
-----
'''Comments'''
Each comment has to be at the start of the line; you can introduce comments
with a hash sign (#) at the start of a line:
# I am a comment.
oo-----
'''Types of statement blocks'''
There are only four kinds of statement blocks in GuiTester:
starting_page
fill_and_submit_form
follow_image_link
follow_link
They are pretty self explanatory. Any script you write will always
start with the '''starting_page''' block. Usually this will be the
index.jhtml of BlueWire and the second statement block will be
'''fill_and_submit_form''' where you will log into the system.
-----
'''Assertions'''
You can do assertions on form fields, titles, URLs and the text of the
page. Assertions always follow the form:
assert_thing "string" <, "string">
Some assertions take one argument (title, URL, text) and one takes two
(field). Examples:
assert_field: "fname", "Jackie"
assert_field: "lname", "Robinson"
assert_title: "this is the page's title"
assert_url: "somedealpage.jhtml"
Assertions throw an exception and the test fails if they are not
true. Assertions are always done after a page has been retrieved in a
given statement block... this is a subtle point and you should reread
that if it doesn't make sense. '''assert_url''' will take the string
and try to match it in the URL returned.
-----
'''Following links'''
follow_image_link:
follow_link:
These will follow a link by the text in the link, or by the ALT text
if it's an image link (like "Browse Deals").
follow_image_link: "Browse Deals"
follow_link: "Get a Quick Quote"
-----
'''Filling in forms'''
form_name:
form_num:
submitbutton_name:
submitbutton_num:
setparam:
These tell what form and what submit button to use... these are only
used with '''fill_and_submit_form''' statement blocks. They take
either a name (as shown in the '''name=""''' attribute of the form or
button) or the number. The number is a Javascript/DOM thing; all forms
are numbered by order of appearance starting at 0.
The '''setparam:''' directive will set a form field, and takes two
arguments: the form field name, and the value. Note that you must
always use double quotes for the arguments, separated by a comma:
setparam: "searchterm", "foo"
setparam: "num_things", "3"
setparam: "options_list", "16"
|
