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
|
Validation of CONFGIT
=====================
The CONFGIT repository contains two types of files we should validate:
the `lorry-controller.conf` file, and the local Lorry files (specified
by the former file in `lorries` sections).
Validate `lorry-controller.conf`
--------------------------------
We'll start by validating the `lorry-controller.conf` file. There's
several aspects here that need to be tested:
* JSON syntax correctness: if the file doesn't parse as JSON, the
WEBAPP should cope and shouldn't change STATEDB in any way.
* Semantic correctness: the file should contain a list of dicts, and
each dict should have the right fields with the right kind of
values. See the `README` for details. Other fields are also allowed,
though ignored. Again, if there's an error, WEBAPP should cope, and
probably shouldn't update STATEDB if there are any problems.
The approach for testing this is to set up an empty STATEDB, then get
WEBAPP to read a `lorry-controller.conf` with various kinds of
brokenness, and after each read verify that STATEDB is still empty.
This doesn't test that if the STATEDB wasn't empty it doesn't change
existing data, but it seems like a reasonable assumption that an
update happens regardless of previous contents of STATEDB, given how
SQL transactions work.
In summary:
* Start WEBAPP without a STATEDB, and have it read its config. Verify
STATEDB is empty.
* Add a `lorry-controller.conf` that is broken in some specific way.
* Tell WEBAPP to re-read its config.
* Verify that WEBAPP gives an error message.
* Verify that STATEDB is still empty.
Repeat this for each type of brokenness we want to ensure WEBAPP
validates for.
SCENARIO validate lorry-controller.conf
GIVEN a new git repository in CONFGIT
AND WEBAPP uses CONFGIT as its configuration directory
AND a running WEBAPP
First of all, have WEBAPP read CONFGIT. This should succeed even if
the `lorry-controller.conf` file doesn't actually exist.
WHEN admin makes request POST /1.0/read-configuration with dummy=value
THEN response matches "Configuration has been updated"
AND STATEDB is empty
Add an empty configuration file. This should still work.
GIVEN an empty lorry-controller.conf in CONFGIT
WHEN admin makes request POST /1.0/read-configuration with dummy=value
THEN response matches "Configuration has been updated"
AND STATEDB is empty
Add a syntactically invalid JSON file.
GIVEN a lorry-controller.conf in CONFGIT containing "blah blah blah"
WHEN admin makes request POST /1.0/read-configuration with dummy=value
THEN response matches "ERROR"
AND STATEDB is empty
Clean up at the end.
FINALLY WEBAPP terminates
Validate local Lorry files
--------------------------
Lorry files (`.lorry`) are consumed by the Lorry program itself, but
also by Lorry Controller. In fact, the ones that are in CONFGIT are
only consumed by Lorry Controller: it reads them in, parses them,
extracts the relevant information, puts that into STATEDB, and then
generates a whole new (temporary) file for each Lorry run.
Lorry Controller doesn't validate the Lorry files much, only
enough that it can extract each separate Lorry specification and feed
them to Lorry one by one. In other words:
* The `.lorry` file must be valid JSON.
* It must be a dict.
* Each key must map to another dict.
* Each inner dict must have a key "type", which maps to a string.
Everything else is left for Lorry itself.
|
