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
|
Implementations
===============
This chapter includes IMPLEMENTS sections for the various steps used
in scenarios.
Managing a WEBAPP instance
--------------------------
We're testing a web application (convenivently named WEBAPP, though
the executable is `lorry-controller-webapp`), so we need to be able to
start it and stop it in scenarios. We start it as a background
process, and keep its PID in `$DATADIR/webapp.pid`. When it's time to
kill it, we kill the process with the PID in that file. This is not
perfect, though it's good enough for our purposes. It doesn't handle
running multiple instances at the same time, which we don't need, and
doens't handle the case of the process dying and the kernel re-using
the PID for something else, which is quite unlikely.
Start an instance of the WEBAPP, using a random port. Record the PID
and the port. Listen only on localhost. We use `start-stop-daemon` to
start the process, so that it can keep running in the background,
but the shell doesn't wait for it to terminate. This way, WEBAPP will
be running until it crashes or is explicitly killed.
IMPLEMENTS GIVEN a running WEBAPP
rm -f "$DATADIR/webapp.pid"
rm -f "$DATADIR/webapp.port"
mkfifo "$DATADIR/webapp.port"
start-stop-daemon -S -x "$SRCDIR/lorry-controller-webapp" \
-b -p "$DATADIR/webapp.pid" -m --verbose \
-- \
--configuration-directory "$DATADIR/confgit" \
--statedb "$DATADIR/webapp.db" \
--status-html "$DATADIR/lc-status.html" \
--log-level debug \
--log "$DATADIR/webapp.log" \
--debug-host 127.0.0.1 \
--debug-port-file "$DATADIR/webapp.port"
port=$(cat "$DATADIR/webapp.port")
rm -f "$DATADIR/webapp.port"
echo "$port" >"$DATADIR/webapp.port"
# Wait for the WEBAPP to actually be ready, i.e., that it's
# listening on its assigned port.
"$SRCDIR/test-wait-for-port" 127.0.0.1 "$port"
Kill the running WEBAPP, using the recorded PID. We need to do this
both as a WHEN and a FINALLY step.
IMPLEMENTS WHEN WEBAPP is terminated
kill_daemon_using_pid_file "$DATADIR/webapp.pid"
IMPLEMENTS FINALLY WEBAPP terminates
kill_daemon_using_pid_file "$DATADIR/webapp.pid"
Also test that WEBAPP isn't running.
IMPLEMENTS THEN WEBAPP isn't running
pid=$(head -n1 "$DATADIR/webapp.pid")
if kill -0 "$pid"
then
echo "process $pid is still running, but should'nt be" 1>&2
exit 1
fi
Managing Lorry Controller configuration
---------------------------------------
We need to be able to create, and change, the `lorry-controller.conf`
file, and other files, in CONFGIT. First of all, we need to create
CONFGIT.
IMPLEMENTS GIVEN a new git repository in (\S+)
git init "$DATADIR/$MATCH_1"
Then we need to create an empty `lorry-controller.conf` file there.
This is not just an empty file, it must be a JSON file that contains
an empty list object.
IMPLEMENTS GIVEN an empty lorry-controller.conf in (\S+)
printf '[]\n' > "$DATADIR/$MATCH_1/lorry-controller.conf"
Further, we need to be able to tell WEBAPP, when it runs, where the
configuration directory is.
IMPLEMENTS GIVEN WEBAPP uses (\S+) as its configuration directory
add_to_config_file "$DATADIR/webapp.conf" \
configuration-directory "$DATADIR/$MATCH_1"
Making and analysing GET requests
---------------------------------
Simple HTTP GET requests are simple. We make the request, and capture
the response: HTTP status code, response headers, response body.
We make the request using the `curl` command line program, which makes
capturing the response quite convenient.
HTTP requests can be made by various entities. For now, we assume
they're all made by the admin.
We check that the HTTP status indicates success, so that every
scenario doesn't need ot check that separately.
IMPLEMENTS WHEN admin makes request GET (\S+)
rm -f "$DATADIR/response.headers"
rm -f "$DATADIR/response.body"
port=$(cat "$DATADIR/webapp.port")
# The timestamp is needed by "THEN static status page got updated"
touch "$DATADIR/request.timestamp"
curl \
-D "$DATADIR/response.headers" \
-o "$DATADIR/response.body" \
--silent --show-error \
"http://127.0.0.1:$port$MATCH_1"
cat "$DATADIR/response.headers"
cat "$DATADIR/response.body"
head -n1 "$DATADIR/response.headers" | grep '^HTTP/1\.[01] 200 '
Check the Content-Type of the response has the desired type.
IMPLEMENTS THEN response is (\S+)
cat "$DATADIR/response.headers"
grep -i "^Content-Type: $MATCH_1" "$DATADIR/response.headers"
A JSON response can then be queried further. The JSON is expected to
be a dict, so that values are accessed by name from the dict. The
value is expresssed as a JSON value in the step.
IMPLEMENTS THEN response has (\S+) set to (.+)
cat "$DATADIR/response.body"
python -c '
import json, os, sys
data = json.load(sys.stdin)
key = os.environ["MATCH_1"]
expected = json.loads(os.environ["MATCH_2"])
value = data[key]
if value != expected:
sys.stderr.write(
"Key {key} has value {value}, but "
"{expected} was expected".format (
key=key, value=value, expected=expected))
sys.exit(1)
' < "$DATADIR/response.body"
In some cases, such as free disk space, we don't care about the actual
value, but we do care that it is there.
IMPLEMENTS THEN response has (\S+) set
cat "$DATADIR/response.body"
python -c '
import json, os, sys
data = json.load(sys.stdin)
key = os.environ["MATCH_1"]
if key not in data:
sys.stderr.write(
"Key {key} is not set, but was expected to be set".format (
key=key))
sys.exit(1)
' < "$DATADIR/response.body"
Status web page
---------------
WEBAPP is expected to update a static HTML pages whenever the
`/1.0/status` request is made. We configure WEBAPP to write it to
`$DATADIR/lc-status.html`. We don't test the contents of the page, but
we do test that it gets updated. We test for the updates by comparing
the modification time of the file with the time of the request. We
know the time of the request thanks to the "WHEN admin makes a
request" step updating the modification time of a file for this
purpose.
IMPLEMENTS THEN static status page got updated
# test -nt isn't useful: the timestamps might be identical, and
# that's OK on filesystems that only store full-second timestamps.
# We generate timestamps in (roughly) ISO 8601 format, with stat,
# and those can be compared using simple string comparison.
status=$(stat -c %y "$DATADIR/lc-status.html")
request=$(stat -c %y "$DATADIR/request.timestamp")
test "$request" = "$status" || test "$request" '<' "$status"
|
