From 11e2ea0f044f1f401f808866bf14ec9ad2683695 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Tue, 22 Apr 2014 15:26:56 +0000 Subject: Provie step to pdo a a body-less POST request --- yarns.webapp/030-queue-management.yarn | 12 ++++++------ yarns.webapp/040-running-jobs.yarn | 16 ++++++++-------- yarns.webapp/050-troves.yarn | 8 ++++---- yarns.webapp/060-validation.yarn | 22 +++++++++++----------- yarns.webapp/900-implementations.yarn | 19 ++++--------------- yarns.webapp/yarn.sh | 24 ++++++++++++++++++++++++ 6 files changed, 57 insertions(+), 44 deletions(-) (limited to 'yarns.webapp') 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 ' +} -- cgit v1.2.1