Provie step to pdo a a body-less POST request

6 files changed, 57 insertions, 44 deletions

diff --git a/yarns.webapp/030-queue-management.yarn b/yarns.webapp/030-queue-management.yarn
index 427bc72..9fca4fb 100644
--- a/yarns.webapp/030-queue-management.yarn
+++ b/yarns.webapp/030-queue-management.yarn
@@ -15,7 +15,7 @@ new jobs, and later to start it again.
     WHEN admin makes request GET /1.0/status
     THEN response has running_queue set to true
 
-    WHEN admin makes request POST /1.0/stop-queue with dummy=value
+    WHEN admin makes request POST /1.0/stop-queue
     AND admin makes request GET /1.0/status
     THEN response has running_queue set to false
 
@@ -32,7 +32,7 @@ new one, and verify that the `running-queue` status is still `true`.
 
 Start the queue again.
 
-    WHEN admin makes request POST /1.0/start-queue with dummy=value
+    WHEN admin makes request POST /1.0/start-queue
     AND admin makes request GET /1.0/status
     THEN response has running_queue set to true
 
@@ -65,7 +65,7 @@ Make WEBAPP read an empty configuration. Or rather, a configuration
 that does not match any existing `.lorry` files.
 
     GIVEN an empty lorry-controller.conf in CONFGIT
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request GET /1.0/list-queue
     THEN response has queue set to []
 
@@ -74,14 +74,14 @@ configuration makes `/list-queue` report it.
 
     GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
     AND lorry-controller.conf in CONFGIT adds lorries *.lorry using prefix upstream
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request GET /1.0/list-queue
     THEN response has queue set to ["upstream/foo"]
 
 If the `.lorry` file is removed, the queue should again become empty.
 
     GIVEN file CONFGIT/foo.lorry is removed
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request GET /1.0/list-queue
     THEN response has queue set to []
 
@@ -89,7 +89,7 @@ Add two Lorries, then make sure they can reordered at will.
 
     GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
     AND Lorry file CONFGIT/bar.lorry with {"bar":{"type":"git","url":"git://bar"}}
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request GET /1.0/list-queue
     THEN response has queue set to ["upstream/bar", "upstream/foo"]
     
diff --git a/yarns.webapp/040-running-jobs.yarn b/yarns.webapp/040-running-jobs.yarn
index 1ffe79d..2bbe906 100644
--- a/yarns.webapp/040-running-jobs.yarn
+++ b/yarns.webapp/040-running-jobs.yarn
@@ -18,7 +18,7 @@ To start with, with an empty run-queue, nothing should be scheduled.
 
 We stop the queue first.
 
-    WHEN admin makes request POST /1.0/stop-queue with dummy=value
+    WHEN admin makes request POST /1.0/stop-queue
 
 Then make sure we don't get a job when we reuqest one.
 
@@ -33,13 +33,13 @@ shouldn't get a job, since the queue isn't set to run yet.
 
     GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
 
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request POST /1.0/give-me-job with host=testhost&pid=123
     THEN response has job_id set to null
 
 Enable the queue, and off we go.
 
-    WHEN admin makes request POST /1.0/start-queue with dummy=value
+    WHEN admin makes request POST /1.0/start-queue
     AND admin makes request POST /1.0/give-me-job with host=testhost&pid=123
     THEN response has job_id set to 1
     AND response has path set to "upstream/foo"
@@ -86,7 +86,7 @@ could, in principle, run two jobs at the same time.
     AND Lorry file CONFGIT/bar.lorry with {"bar":{"type":"git","url":"git://bar"}}
     AND WEBAPP uses CONFGIT as its configuration directory
     AND a running WEBAPP
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
 
 Check the current set of the `max_jobs` setting.
 
@@ -130,8 +130,8 @@ we did for the successful job scenario.
     AND WEBAPP uses CONFGIT as its configuration directory
     AND a running WEBAPP
     AND Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
-    AND admin makes request POST /1.0/start-queue with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
+    AND admin makes request POST /1.0/start-queue
     AND admin makes request POST /1.0/give-me-job with host=testhost&pid=123
     THEN response has job_id set to 1
     AND response has path set to "upstream/foo"
@@ -183,7 +183,7 @@ to have the test suite fail when running on slow devices.
     AND Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
     AND WEBAPP uses CONFGIT as its configuration directory
     AND a running WEBAPP
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
 
 Pretend it is the start of time.
 
@@ -231,7 +231,7 @@ Setup.
     AND WEBAPP uses CONFGIT as its configuration directory
     AND a running WEBAPP
     GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
 
 Start job 1.
 
diff --git a/yarns.webapp/050-troves.yarn b/yarns.webapp/050-troves.yarn
index 8737306..e2f89e8 100644
--- a/yarns.webapp/050-troves.yarn
+++ b/yarns.webapp/050-troves.yarn
@@ -36,7 +36,7 @@ reads that, it should list the added Trove in status.
 
     GIVEN lorry-controller.conf in CONFGIT adds trove example-trove
     AND lorry-controller.conf in CONFGIT has prefixmap example:example for example-trove
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request GET /1.0/status
     THEN response has troves item 0 field trovehost set to "example-trove"
 
@@ -48,7 +48,7 @@ repositories from the remote Trove.
 If we tell WEBAPP to fetch the list, we should see repositories.
 
     GIVEN remote Trove example-trove has repository example/foo
-    WHEN admin makes request POST /1.0/ls-troves with dummy=value
+    WHEN admin makes request POST /1.0/ls-troves
     AND admin makes request GET /1.0/list-queue
     THEN response has queue set to ["example/foo"]
 
@@ -56,7 +56,7 @@ If we re-read the configuration again, without any changes to it or to
 the fake Trove's repository list, the same Troves and Lorry specs
 should remain in STATEDB. (It wasn't always thus, due to a bug.)
 
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     AND admin makes request GET /1.0/status
     THEN response has troves item 0 field trovehost set to "example-trove"
     WHEN admin makes request GET /1.0/list-queue
@@ -67,7 +67,7 @@ avoid disasters. However, it will be removed from the Trove's STATEDB,
 and it won't be lorried anymore.
 
     GIVEN remote Trove example-trove doesn't have repository example/foo
-    WHEN admin makes request POST /1.0/ls-troves with dummy=value
+    WHEN admin makes request POST /1.0/ls-troves
     AND admin makes request GET /1.0/list-queue
     THEN response has queue set to []
 
diff --git a/yarns.webapp/060-validation.yarn b/yarns.webapp/060-validation.yarn
index 989c80b..91b3b54 100644
--- a/yarns.webapp/060-validation.yarn
+++ b/yarns.webapp/060-validation.yarn
@@ -47,7 +47,7 @@ validates for.
 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
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "Configuration has been updated"
     AND STATEDB is empty
 
@@ -55,14 +55,14 @@ Add an empty configuration file. This is different from a file
 containing an empty JSON list. It should be treated as an error.
 
     GIVEN a lorry-controller.conf in CONFGIT containing ""
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "ERROR"
     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
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "ERROR"
     AND STATEDB is empty
 
@@ -71,7 +71,7 @@ Replace the bad JSON file with one that has an unknown section (no
 an artifact of how yarn steps are implemented and is OK.
 
     GIVEN a lorry-controller.conf in CONFGIT containing "[{"foo": "bar"}]"
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "ERROR"
     AND STATEDB is empty
 
@@ -79,7 +79,7 @@ What about a section that has a `type` field, but it's set to a
 non-sensical value?
 
     GIVEN a lorry-controller.conf in CONFGIT containing "[{"type": "BACKUPS!"}]"
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "ERROR"
     AND STATEDB is empty
 
@@ -134,7 +134,7 @@ Firstly, some setup.
 
 Make sure WEBAPP handles there not being any `.lorry` files.
 
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "has been updated"
     AND STATEDB is empty
     WHEN admin makes request GET /1.0/list-queue
@@ -143,7 +143,7 @@ Make sure WEBAPP handles there not being any `.lorry` files.
 Add a `.lorry` file that contains broken JSON.
 
     GIVEN Lorry file CONFGIT/notjson.lorry with THIS IS NOT JSON
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "has been updated"
     AND STATEDB is empty
     WHEN admin makes request GET /1.0/list-queue
@@ -152,7 +152,7 @@ Add a `.lorry` file that contains broken JSON.
 Add a `.lorry` file that is valid JSON, but is not a dict.
 
     GIVEN Lorry file CONFGIT/notadict.lorry with [1,2,3]
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "has been updated"
     AND STATEDB is empty
     WHEN admin makes request GET /1.0/list-queue
@@ -161,7 +161,7 @@ Add a `.lorry` file that is valid JSON, but is not a dict.
 Add a `.lorry` that is a dict, but doesn't map keys to dicts.
 
     GIVEN Lorry file CONFGIT/notadictofdicts.lorry with { "foo": 1 }
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "has been updated"
     AND STATEDB is empty
     WHEN admin makes request GET /1.0/list-queue
@@ -170,7 +170,7 @@ Add a `.lorry` that is a dict, but doesn't map keys to dicts.
 Add a `.lorry` whose inner dict does not have a `type` field.
 
     GIVEN Lorry file CONFGIT/notype.lorry with { "foo": { "bar": "yo" }}
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "has been updated"
     AND STATEDB is empty
     WHEN admin makes request GET /1.0/list-queue
@@ -180,7 +180,7 @@ Add a `.lorry` that is A-OK. This should work even when there are some
 broken ones too.
 
     GIVEN Lorry file CONFGIT/a-ok.lorry with { "foo": { "type": "git", "url": "git://example.com/foo" }}
-    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    WHEN admin makes request POST /1.0/read-configuration
     THEN response matches "has been updated"
     WHEN admin makes request GET /1.0/list-queue
     THEN response has queue set to ["upstream/foo"]
diff --git a/yarns.webapp/900-implementations.yarn b/yarns.webapp/900-implementations.yarn
index 859bb40..dba32e1 100644
--- a/yarns.webapp/900-implementations.yarn
+++ b/yarns.webapp/900-implementations.yarn
@@ -319,23 +319,12 @@ A POST request always has a body. The body consists of `foo=bar`
 pairs, separated by `&` signs.
 
     IMPLEMENTS WHEN (\S+) makes request POST (\S+) with (.*)
-    > "$DATADIR/response.headers"
-    > "$DATADIR/response.body"
-    port=$(cat "$DATADIR/webapp.port")
+    post_request "$MATCH_2" "$MATCH_3"
 
-    # The timestamp is needed by "THEN static status page got updated"
-    touch "$DATADIR/request.timestamp"
+Except, sometimes we don't have a useful body to give. So we don't.
 
-    curl \
-        -D "$DATADIR/response.headers" \
-        -o "$DATADIR/response.body" \
-        --silent --show-error \
-        --request POST \
-        --data "$MATCH_3" \
-        "http://127.0.0.1:$port$MATCH_2"
-    cat "$DATADIR/response.headers"
-    cat "$DATADIR/response.body"
-    head -n1 "$DATADIR/response.headers" | grep '^HTTP/1\.[01] 200 '
+    IMPLEMENTS WHEN (\S+) makes request POST (\S+)
+    post_request "$MATCH_2" dummy=value
 
 Check the Content-Type of the response has the desired type.
 
diff --git a/yarns.webapp/yarn.sh b/yarns.webapp/yarn.sh
index 6f93a5f..f3f7bc2 100644
--- a/yarns.webapp/yarn.sh
+++ b/yarns.webapp/yarn.sh
@@ -96,3 +96,27 @@ start_webapp()
     # listening on its assigned port.
     "$SRCDIR/test-wait-for-port" 127.0.0.1 "$port"
 }
+
+
+# Make a POST request.
+
+post_request()
+{
+    > "$DATADIR/response.headers"
+    > "$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 \
+        --request POST \
+        --data "$2" \
+        "http://127.0.0.1:$port$1"
+    cat "$DATADIR/response.headers"
+    cat "$DATADIR/response.body"
+    head -n1 "$DATADIR/response.headers" | grep '^HTTP/1\.[01] 200 '
+}