mirror of
https://github.com/Orange-OpenSource/hurl.git
synced 2025-01-03 16:54:13 +03:00
fix grammar in docs
This commit is contained in:
Zoltan Klinger
parent
5bc24bd0cf
commit
a375af91d4
12
README.md
12
README.md
@ -90,7 +90,7 @@ SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
|
||||
HTTP/1.1 200
|
||||
```
|
||||
|
||||
Hurl can also be used to test HTTP endpoints performances:
|
||||
Hurl can also be used to performance test HTTP endpoints:
|
||||
|
||||
```hurl
|
||||
GET https://example.org/api/v1/pets
|
||||
@ -100,7 +100,7 @@ HTTP/1.0 200
|
||||
duration < 1000 # Duration in ms
|
||||
```
|
||||
|
||||
And responses bytes content
|
||||
And response bytes
|
||||
|
||||
```hurl
|
||||
GET https://example.org/data.tar.gz
|
||||
@ -122,8 +122,8 @@ sha256 == hex,039058c6f2c0cb492c533b0a4d14ef77cc0f78abccced5287d84a1a2011cfb81;
|
||||
# Powered by curl
|
||||
|
||||
Hurl is a lightweight binary written in [Rust]. Under the hood, Hurl HTTP engine is
|
||||
powered by [libcurl], one of the most powerful and reliable file transfer library.
|
||||
With its text file format, Hurl adds syntactic sugar to run and tests HTTP requests,
|
||||
powered by [libcurl], one of the most powerful and reliable file transfer libraries.
|
||||
With its text file format, Hurl adds syntactic sugar to run and test HTTP requests,
|
||||
but it's still the [curl] that we love.
|
||||
|
||||
# Feedbacks
|
||||
@ -293,7 +293,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
|
||||
```
|
||||
|
||||
Basic authentication allows per request authentication.
|
||||
If you want to add basic authentication to all the request of a Hurl file
|
||||
If you want to add basic authentication to all the requests of a Hurl file
|
||||
you could use [`-u/--user` option].
|
||||
|
||||
## Sending Data
|
||||
@ -705,7 +705,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
|
||||
|
||||
## Options
|
||||
|
||||
Options that exist in curl have exactly the same semantic.
|
||||
Options that exist in curl have exactly the same semantics.
|
||||
|
||||
Options specified on the command line are defined for every Hurl file's entry.
|
||||
|
||||
|
||||
@ -287,7 +287,7 @@ cookie "LSID[SameSite]" equals "Lax"
|
||||
```
|
||||
|
||||
> `Secure` and `HttpOnly` attributes can only be tested with `exists` or `not exists` predicates
|
||||
> to reflect the [Set-Cookie header] semantic (in other words, queries `<cookie-name>[HttpOnly]`
|
||||
> to reflect the [Set-Cookie header] semantics (in other words, queries `<cookie-name>[HttpOnly]`
|
||||
> and `<cookie-name>[Secure]` don't return boolean).
|
||||
|
||||
### Body assert
|
||||
|
||||
@ -3,11 +3,11 @@
|
||||
## Captures
|
||||
|
||||
Captures are optional values captured from the HTTP response, in a named variable. Captures can be the
|
||||
response status code, part or the entire of the body, and response headers.
|
||||
response status code, part of or the entire the body, and response headers.
|
||||
|
||||
Captured variables are available through a run session; each new value of a given variable overrides the last value.
|
||||
|
||||
Captures allow using data from one request to another request, when working with
|
||||
Captures allow using data from one request in another request, when working with
|
||||
[CSRF tokens] for instance. Variables can also be initialized at the start of the
|
||||
session, by passing [variable values], or can be used in [templates].
|
||||
|
||||
@ -169,7 +169,7 @@ HTTP/1.1 200
|
||||
```
|
||||
|
||||
XPath captures are not limited to node values (like string, or boolean); any
|
||||
valid XPath can be captured and assert with variable asserts.
|
||||
valid XPath can be captured and asserted with variable asserts.
|
||||
|
||||
```hurl
|
||||
# Test that the XML endpoint return 200 pets
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Definition
|
||||
|
||||
A Hurl file is a list of entry, each entry being a mandatory [request], optionally followed by a [response].
|
||||
A Hurl file is a list of entries, each entry being a mandatory [request], optionally followed by a [response].
|
||||
|
||||
Responses are not mandatory, a Hurl file consisting only of requests is perfectly valid. To sum up, responses can be used
|
||||
to [capture values] to perform subsequent requests, or [add asserts to HTTP responses].
|
||||
|
||||
@ -88,7 +88,7 @@ SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
|
||||
HTTP/1.1 200
|
||||
```
|
||||
|
||||
Hurl can also be used to test HTTP endpoints performances:
|
||||
Hurl can also be used to performance test HTTP endpoints:
|
||||
|
||||
```hurl
|
||||
GET https://example.org/api/v1/pets
|
||||
@ -98,7 +98,7 @@ HTTP/1.0 200
|
||||
duration < 1000 # Duration in ms
|
||||
```
|
||||
|
||||
And responses bytes content
|
||||
And response bytes
|
||||
|
||||
```hurl
|
||||
GET https://example.org/data.tar.gz
|
||||
@ -120,8 +120,8 @@ sha256 == hex,039058c6f2c0cb492c533b0a4d14ef77cc0f78abccced5287d84a1a2011cfb81;
|
||||
# Powered by curl
|
||||
|
||||
Hurl is a lightweight binary written in [Rust]. Under the hood, Hurl HTTP engine is
|
||||
powered by [libcurl], one of the most powerful and reliable file transfer library.
|
||||
With its text file format, Hurl adds syntactic sugar to run and tests HTTP requests,
|
||||
powered by [libcurl], one of the most powerful and reliable file transfer libraries.
|
||||
With its text file format, Hurl adds syntactic sugar to run and test HTTP requests,
|
||||
but it's still the [curl] that we love.
|
||||
|
||||
# Feedbacks
|
||||
|
||||
@ -45,7 +45,7 @@ jsonpath "$.slideshow.title" == "A beautiful ✈!"
|
||||
jsonpath "$.slideshow.title" == "A beautiful \u{2708}!"
|
||||
```
|
||||
|
||||
In some case, (in headers value, etc..), you will also need to escape # to distinguish from a comment.
|
||||
In some case, (in headers value, etc..), you will also need to escape # to distinguish it from a comment.
|
||||
In the following example:
|
||||
|
||||
```hurl
|
||||
|
||||
@ -121,7 +121,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
|
||||
|
||||
## Options
|
||||
|
||||
Options that exist in curl have exactly the same semantic.
|
||||
Options that exist in curl have exactly the same semantics.
|
||||
|
||||
Options specified on the command line are defined for every Hurl file's entry.
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.TH hurl 1 "25 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
|
||||
.TH hurl 1 "28 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
|
||||
.SH NAME
|
||||
|
||||
hurl - run and test HTTP requests.
|
||||
@ -104,7 +104,7 @@ More information on asserts can be found here \fIhttps://hurl.dev/docs/asserting
|
||||
|
||||
.SH OPTIONS
|
||||
|
||||
Options that exist in curl have exactly the same semantic.
|
||||
Options that exist in curl have exactly the same semantics.
|
||||
|
||||
Options specified on the command line are defined for every Hurl file's entry.
|
||||
|
||||
|
||||
@ -119,7 +119,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
|
||||
|
||||
## OPTIONS
|
||||
|
||||
Options that exist in curl have exactly the same semantic.
|
||||
Options that exist in curl have exactly the same semantics.
|
||||
|
||||
Options specified on the command line are defined for every Hurl file's entry.
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.TH hurl 1 "25 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
|
||||
.TH hurl 1 "28 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
|
||||
.SH NAME
|
||||
|
||||
hurlfmt - format Hurl files
|
||||
@ -13,7 +13,7 @@ hurlfmt - format Hurl files
|
||||
.SH DESCRIPTION
|
||||
|
||||
.B hurlfmt
|
||||
formats Hurl files and converts to other formats.
|
||||
formats Hurl files and converts them to other formats.
|
||||
|
||||
With no FILE, read standard input.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ hurlfmt - format Hurl files
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
**hurlfmt** formats Hurl files and converts to other formats.
|
||||
**hurlfmt** formats Hurl files and converts them to other formats.
|
||||
|
||||
With no FILE, read standard input.
|
||||
|
||||
|
||||
@ -333,7 +333,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
|
||||
```
|
||||
|
||||
Basic authentication allows per request authentication.
|
||||
If you want to add basic authentication to all the request of a Hurl file
|
||||
If you want to add basic authentication to all the requests of a Hurl file
|
||||
you can use [`-u/--user` option].
|
||||
|
||||
### Body
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
## Definition
|
||||
|
||||
Responses can be used to capture values to perform subsequent requests, or add asserts to HTTP responses. Response on
|
||||
requests are optional, a Hurl file can only be a sequence of [requests].
|
||||
requests are optional, a Hurl file can just consist of a sequence of [requests].
|
||||
|
||||
A response describes the expected HTTP response, with mandatory [version and status], followed by optional [headers],
|
||||
[captures], [asserts] and [body]. Assertions in the expected HTTP response describe values of the received HTTP response.
|
||||
|
||||
@ -84,7 +84,7 @@ To use variables in your tests, you can:
|
||||
- use [`--variables-file` option]
|
||||
- define environment variables, for instance `HURL_foo=bar`
|
||||
|
||||
You will find a detail description in the [Injecting Variables] section of the doc.
|
||||
You will find a detailed description in the [Injecting Variables] section of the docs.
|
||||
|
||||
[`--output /dev/null`]: /docs/manual.md#output
|
||||
[`--test`]: /docs/manual.md#test
|
||||
@ -93,4 +93,4 @@ You will find a detail description in the [Injecting Variables] section of the d
|
||||
[`--glob` option]: /docs/manual.md#glob
|
||||
[`--variable` option]: /docs/manual.md#variable
|
||||
[`--variables-file` option]: /docs/manual.md#variables-file
|
||||
[Injecting Variables]: /docs/templates.md#injecting-variables
|
||||
[Injecting Variables]: /docs/templates.md#injecting-variables
|
||||
|
||||
@ -82,7 +82,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
|
||||
```
|
||||
|
||||
Basic authentication allows per request authentication.
|
||||
If you want to add basic authentication to all the request of a Hurl file
|
||||
If you want to add basic authentication to all the requests of a Hurl file
|
||||
you could use [`-u/--user` option].
|
||||
|
||||
## Sending Data
|
||||
@ -383,4 +383,4 @@ bytes startsWith hex,efbbbf;
|
||||
[`-u/--user` option]: /docs/manual.md#user
|
||||
[curl]: https://curl.se
|
||||
[entry]: /docs/entry.md
|
||||
[`--test` option]: /docs/manual.md#test
|
||||
[`--test` option]: /docs/manual.md#test
|
||||
|
||||
@ -19,7 +19,7 @@ X-CSRF-TOKEN: {{csrf_token}}
|
||||
HTTP/1.1 302
|
||||
```
|
||||
|
||||
In this example, we capture the value of the [CSRF token] from the body a first response, and inject it
|
||||
In this example, we capture the value of the [CSRF token] from the body of the first response, and inject it
|
||||
as a header in the next POST request.
|
||||
|
||||
```hurl
|
||||
@ -39,7 +39,7 @@ In this second example, we capture the body in a variable `index`, and reuse thi
|
||||
|
||||
## Types
|
||||
|
||||
Variable are typed, and can be either string, bool, number, `null` or collections. Depending on the variable type,
|
||||
Variables are typed, and can be either string, bool, number, `null` or collections. Depending on the variable type,
|
||||
templates can be rendered differently. Let's say we have captured an integer value into a variable named
|
||||
`count`:
|
||||
|
||||
|
||||
@ -187,7 +187,7 @@ header "Content-Type" == "text/html;charset=UTF-8"
|
||||
> In this case, the `header` query will return collections and could be tested with
|
||||
> `countEqual` or `include` predicates.
|
||||
|
||||
For HTTP headers, we can also use an [implicit header assert]. You can use indifferently implicit or
|
||||
For HTTP headers, we can also use an [implicit header assert]. You can use either implicit or
|
||||
explicit header assert: the implicit one allows you to only check the exact value of the header,
|
||||
while the explicit one allows you to use other [predicates] (like `contains`, `startsWith`, `matches` etc...).
|
||||
|
||||
@ -242,7 +242,7 @@ it simplifies tests on cookies, particularly when there are multiple `Set-Cookie
|
||||
> has no Javascript runtime and stays close to the HTTP layer. With others tools relying on headless browser, it can be
|
||||
> difficult to access some HTTP requests attributes, like `Set-Cookie` header.
|
||||
|
||||
So to test that our server is responding a `HttpOnly` session cookie, we can modify our file and add cookie asserts.
|
||||
So to test that our server is responding with a `HttpOnly` session cookie, we can modify our file and add cookie asserts.
|
||||
|
||||
4. Add two cookie asserts on the cookie `JESSIONID`:
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
# Captures
|
||||
|
||||
We have seen how to chain requests in a Hurl file. In some use cases, you want
|
||||
to use data from one request and inject it in another one. That what captures
|
||||
to use data from one request and inject it in another one. That's what captures
|
||||
are all about.
|
||||
|
||||
## Capturing a CSRF Token
|
||||
|
||||
In our quiz application, user can create a quiz at <http://localhost:8080/new-quiz>.
|
||||
In our quiz application, a user can create a quiz at <http://localhost:8080/new-quiz>.
|
||||
The HTML page is a [form] where the user can input:
|
||||
|
||||
- a required name
|
||||
@ -40,7 +40,7 @@ page of the new quiz, indicating creation success.
|
||||
|
||||
Let's try to test it!
|
||||
|
||||
Form values can be sent using a [Form parameters section], with each key followed by it
|
||||
Form values can be sent using a [Form parameters section], with each key followed by its
|
||||
corresponding value.
|
||||
|
||||
1. Create a new file named `create-quiz.hurl`:
|
||||
@ -59,7 +59,7 @@ HTTP/1.1 302
|
||||
```
|
||||
|
||||
> When sending form data with a Form parameters section, you don't need to set the
|
||||
> `Content-Type` HTTP header: Hurl enfers that the content type of the request is `application/x-www-form-urlencoded`.
|
||||
> `Content-Type` HTTP header: Hurl infers that the content type of the request is `application/x-www-form-urlencoded`.
|
||||
|
||||
2. Run `create-quiz.hurl`:
|
||||
|
||||
@ -239,7 +239,7 @@ detail_url: header "Location"
|
||||
header "Location" matches "/quiz/detail/[a-f0-9]{8}"
|
||||
```
|
||||
|
||||
3. Add a request to get the detail page where the user has been redirected:
|
||||
3. Add a request to get the detail page that the user has been redirected to:
|
||||
|
||||
```hurl
|
||||
# First, get the quiz creation page to capture
|
||||
@ -307,7 +307,7 @@ HTTP/1.1 200
|
||||
```
|
||||
|
||||
We have seen how to [capture response data] in a variable and use it in others request.
|
||||
Captures and asserts share the sames queries, and can be inter-mixed in the same response.
|
||||
Captures and asserts share the same queries, and can be inter-mixed in the same response.
|
||||
Finally, Hurl doesn't follow redirect by default, but captures can be used to run each step
|
||||
of a redirection.
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ cookie "JSESSIONID[HttpOnly]" exists
|
||||
```
|
||||
|
||||
We're only running one HTTP request and have already added lots of tests on the response. Don't hesitate to add
|
||||
many tests, the more asserts you will write, the less fragile will be your tests suite.
|
||||
many tests, the more asserts you write, the less fragile your tests suite will become.
|
||||
|
||||
Now, we want to perform other HTTP requests and keep adding tests. In the same file, we can simply write another
|
||||
request following our first request. Let's say we want to test that we have a [404 page] on a broken link:
|
||||
@ -57,7 +57,7 @@ xpath "string(//h1)" == "Error 404, Page not Found!"
|
||||
Now, we have two entries in our Hurl file: each entry is composed of one request and one expected response
|
||||
description.
|
||||
|
||||
> In a Hurl file, response description are optional. We could also have written
|
||||
> In a Hurl file, response descriptions are optional. We could also have written
|
||||
> our file with only requests:
|
||||
>
|
||||
> ```hurl
|
||||
@ -80,7 +80,7 @@ Failed files: 0 (0.0%)
|
||||
Duration: 12 ms
|
||||
```
|
||||
|
||||
We can see that the test is still ok, now two requests are ran in chain, and each response can be
|
||||
We can see that the test is still ok, now two requests are being run in sequence, and each response can be
|
||||
tested independently.
|
||||
|
||||
## Test REST Api
|
||||
@ -112,7 +112,7 @@ So, our health api returns this JSON resource:
|
||||
```
|
||||
|
||||
We can test it with a [JsonPath assert]. JsonPath asserts have the same structure as XPath asserts: a query
|
||||
followed by a predicate. [JsonPath query] are simple expressions to inspect a JSON object.
|
||||
followed by a predicate. A [JsonPath query] is a simple expression to inspect a JSON object.
|
||||
|
||||
2. Modify `basic.hurl` to add a third request that asserts our </api/health> REST api:
|
||||
|
||||
@ -134,10 +134,10 @@ jsonpath "$.healthy" == true
|
||||
jsonpath "$.operationId" exists
|
||||
```
|
||||
|
||||
Like XPath assert, JsonPath predicates values are typed. String, boolean, number and
|
||||
collections are supported. Let's practice it by using another api. In our Quiz model, a
|
||||
Like XPath assert, JsonPath predicate values are typed. String, boolean, number and
|
||||
collections are supported. Let's practice writing JsonPath asserts by using another api. In our Quiz model, a
|
||||
quiz is a set of questions, and a question resource is exposed through a
|
||||
REST api exposed et <http://localhost:8080/api/questions>. We can use it to add checks on getting questions
|
||||
REST api exposed at <http://localhost:8080/api/questions>. We can use it to add checks on getting questions
|
||||
through the api endpoint.
|
||||
|
||||
3. Add JSONPath asserts on the </api/questions> REST apis:
|
||||
@ -167,7 +167,7 @@ jsonpath "$[0].title" == "What is a pennyroyal?"
|
||||
> in our Quiz application. That's something you don't want to do when building
|
||||
> your application, you want to build an app production ready. A better way to
|
||||
> do this should have been to expose a "debug" or "integration" mode on our app
|
||||
> positioned by environment variables. If our app is launched in "integration" mode,
|
||||
> defined by environment variables. If our app is launched in "integration" mode,
|
||||
> mocked data is used and asserts can be tested on known values. Our app could also use
|
||||
> a mocked database, configured in our tests suits.
|
||||
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
# CI/CD Integration
|
||||
|
||||
Up until now, we have run our tests files locally. Now, we want to integrate
|
||||
Up until now, we have run our test files locally. Now, we want to integrate
|
||||
them in a CI/CD pipeline (like [GitHub Actions] or [GitLab CI/CD pipelines]). As
|
||||
Hurl is very fast, we're going to run our tests on each commit of our project,
|
||||
drastically improving the project quality.
|
||||
|
||||
A typical web project pipeline is:
|
||||
|
||||
- build the application, run units tests and static code analysis,
|
||||
- build the application, run unit tests and static code analysis,
|
||||
- publish the application image to a Docker registry,
|
||||
- pull the application image and run integration tests.
|
||||
|
||||
@ -38,7 +38,7 @@ $ vi integration/create-quiz.hurl
|
||||
|
||||
# Import <a href="https://raw.githubusercontent.com/jcamiel/quiz/master/integration/create-quiz.hurl">create-quiz.hurl</a> here!</code></pre>
|
||||
|
||||
Next, we are going to write a first version of our integration script that will
|
||||
Next, we are going to write the first version of our integration script that will
|
||||
just pull the Quiz image and run it:
|
||||
|
||||
2. Create a script named `bin/integration.sh` with the following content:
|
||||
@ -72,12 +72,12 @@ quiz
|
||||
|
||||
Now, we have a basic script that starts our container. Before adding our
|
||||
integration tests, we need to ensure that our application server is ready: the
|
||||
container have started, but the application server can take a few seconds to be
|
||||
container has started, but the application server can take a few seconds to be
|
||||
really ready to accept incoming HTTP requests.
|
||||
|
||||
To do so, we can test our health api. With a function `wait_for_url`,
|
||||
we use Hurl to check a given url to return a `200 OK`. We loop on this function
|
||||
until the check succeed. Once the test has succeeded, we stop the container.
|
||||
until the check succeeds. Once the test has succeeded, we stop the container.
|
||||
|
||||
5. Modify `bin/integration.sh` to wait for the application to be ready:
|
||||
|
||||
@ -258,7 +258,7 @@ TBD
|
||||
|
||||
## Recap
|
||||
|
||||
In less than half an hour, we have added a fully CI/CD pipeline to our project.
|
||||
In less than half an hour, we have added a full CI/CD pipeline to our project.
|
||||
Now, we can add more Hurl tests and start developing new features with confidence!
|
||||
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
# Debug Tips
|
||||
|
||||
Now that we have many requests in our test file, let's review some tips to debug the executed HTTP exchanges.
|
||||
Now that we have many requests in our test file, let's review some tips on how to debug the executed HTTP exchanges.
|
||||
|
||||
## Verbose Mode
|
||||
|
||||
### Using --verbose and --very-verbose for all entries
|
||||
|
||||
We can run our test with [`-v/--verbose` option]. In this mode, each entry is displayed, with debugging
|
||||
We can run our test with [`-v/--verbose` option]. In this mode, each entry is displayed with debugging
|
||||
information like request HTTP headers, response HTTP headers, cookie storage, duration etc...
|
||||
|
||||
```shell
|
||||
@ -87,7 +87,7 @@ $ hurl --verbose --no-output basic.hurl
|
||||
...
|
||||
```
|
||||
|
||||
Lines beginning by `*` are debug info, lines that begin by `>` are HTTP request headers and lines that begin with
|
||||
Lines beginning with `*` are debug info, lines that begin with `>` are HTTP request headers and lines that begin with
|
||||
`<` are HTTP response headers.
|
||||
|
||||
In verbose mode, HTTP request and response bodies are not displayed in the debug logs. If you need to inspect the
|
||||
@ -215,7 +215,7 @@ $ hurl --very-verbose --no-output basic.hurl
|
||||
|
||||
### Debugging a specific entry
|
||||
|
||||
If you have a lots of entry (a request / response pair) in your Hurl file, using [`--verbose`] or [`--very-verbose`]
|
||||
If you have a lot of entries (request / response pairs) in your Hurl file, using [`--verbose`] or [`--very-verbose`]
|
||||
can produce a lot of logs and can be difficult to analyse. Instead of passing options to the command line, you can
|
||||
use an `[Options]` section that will activate logs only for the specified entry:
|
||||
|
||||
@ -371,7 +371,7 @@ Date: Sun, 06 Jun 2021 15:11:31 GMT
|
||||
[{"id":"c0d80047-4fbe-4d45-a005-91b5c7018b34","created":"1995-12-17T03:24:00Z"....
|
||||
```
|
||||
|
||||
If you want to inspect any entry other than the last entry, you can run your test to a
|
||||
If you want to inspect any entry other than the last one, you can run your test to a
|
||||
given entry with the [`--to-entry` option], starting at index 1:
|
||||
|
||||
```shell
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Security
|
||||
|
||||
In the previous part, we have tested the basic creation of a quiz, through the <http://localhost:8080/new-quiz>
|
||||
endpoint. Our test file `create-quiz.hurl` is now:
|
||||
endpoint. Our test file `create-quiz.hurl` now looks like:
|
||||
|
||||
```hurl
|
||||
# First, get the quiz creation page to capture
|
||||
@ -53,8 +53,8 @@ Our HTML form is:
|
||||
```
|
||||
|
||||
The first input, name, has validation HTML attributes: `minlenght="4"`, `maxlenght="32"` and `required`.
|
||||
In a browser, these attributes will prevent user to fill invalid data like a missing value or a name too long. If your
|
||||
tests rely on a "headless" browser, this type of validation can block you to test your server-side
|
||||
In a browser, these attributes will prevent the user from entering invalid data like a missing value or a name that is too long. If your
|
||||
tests rely on a "headless" browser, it can stop you from testing your server-side
|
||||
validation. Client-side validation can also use JavaScript, and it can be a challenge to send invalid data to your server.
|
||||
|
||||
But server-side validation is critical to secure your app. You must always validate and sanitize data on your backend,
|
||||
@ -179,14 +179,14 @@ Duration: 41 ms
|
||||
So Hurl, being close to the HTTP layer, has no "browser protection" / client-side validation: it facilitates
|
||||
the testing of your app's security with no preconception.
|
||||
|
||||
Another use case is checking if there are no comment in your served HTML. These leaks can reveal sensitive information
|
||||
Another use case is checking if there are no comments in your served HTML. Comments can reveal sensitive information
|
||||
and [is it recommended] to trim HTML comments in your production files.
|
||||
|
||||
Popular front-end construction technologies use client-side JavaScript like [ReactJS] or [Vue.js].
|
||||
If you use one of this framework, and you inspect the DOM with the browser developer tools, you won't see any comment
|
||||
because the framework is managing the DOM and removing them.
|
||||
Popular front-end frameworks like [ReactJS] or [Vue.js] use client-side JavaScript.
|
||||
If you use one of these frameworks, and you inspect the DOM with the browser developer tools, you won't see any comments
|
||||
because the framework is managing the DOM and is removing them.
|
||||
|
||||
But, if you look at the HTML page sent on the network, i.e. is the real HTML document sent by the
|
||||
But, if you look at the HTML page sent on the network, i.e. the real HTML document sent by the
|
||||
server (and not _the document dynamically created by the framework_), you can still see those HTML comments.
|
||||
|
||||
With Hurl, you will be able to check the content of the _real_ network data.
|
||||
|
||||
@ -115,8 +115,8 @@ $ hurl basic.hurl
|
||||
```
|
||||
|
||||
|
||||
As there are no response description, this basic test only checks that an HTTP server is running at
|
||||
<http://localhost:8080> and responds _something_. If the server had a problem on this endpoint, and had responded
|
||||
As there is no response description, this basic test only checks that an HTTP server is running at
|
||||
<http://localhost:8080> and responds with _something_. If the server had a problem on this endpoint, and had responded
|
||||
with a [`500 Internal Server Error`], Hurl would have just executed successfully the HTTP request,
|
||||
without checking the actual HTTP response.
|
||||
|
||||
@ -211,7 +211,7 @@ HTTP/1.1 200
|
||||
|
||||
That's it, this is your first Hurl file!
|
||||
|
||||
This is really a basic test, but Hurl's file format strength is its simplicity.
|
||||
This is really a basic test, but it shows how powerful Hurl's simple file format is.
|
||||
We're going to see in the next section how to improve our tests while keeping it really simple.
|
||||
|
||||
[GitHub Action]: https://github.com/features/actions
|
||||
|
||||
@ -90,7 +90,7 @@ SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
|
||||
HTTP/1.1 200
|
||||
```
|
||||
|
||||
Hurl can also be used to test HTTP endpoints performances:
|
||||
Hurl can also be used to performance test HTTP endpoints:
|
||||
|
||||
```hurl
|
||||
GET https://example.org/api/v1/pets
|
||||
@ -100,7 +100,7 @@ HTTP/1.0 200
|
||||
duration < 1000 # Duration in ms
|
||||
```
|
||||
|
||||
And responses bytes content
|
||||
And response bytes
|
||||
|
||||
```hurl
|
||||
GET https://example.org/data.tar.gz
|
||||
@ -122,8 +122,8 @@ sha256 == hex,039058c6f2c0cb492c533b0a4d14ef77cc0f78abccced5287d84a1a2011cfb81;
|
||||
# Powered by curl
|
||||
|
||||
Hurl is a lightweight binary written in [Rust]. Under the hood, Hurl HTTP engine is
|
||||
powered by [libcurl], one of the most powerful and reliable file transfer library.
|
||||
With its text file format, Hurl adds syntactic sugar to run and tests HTTP requests,
|
||||
powered by [libcurl], one of the most powerful and reliable file transfer libraries.
|
||||
With its text file format, Hurl adds syntactic sugar to run and test HTTP requests,
|
||||
but it's still the [curl] that we love.
|
||||
|
||||
# Feedbacks
|
||||
@ -293,7 +293,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
|
||||
```
|
||||
|
||||
Basic authentication allows per request authentication.
|
||||
If you want to add basic authentication to all the request of a Hurl file
|
||||
If you want to add basic authentication to all the requests of a Hurl file
|
||||
you could use [`-u/--user` option].
|
||||
|
||||
## Sending Data
|
||||
@ -705,7 +705,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
|
||||
|
||||
## Options
|
||||
|
||||
Options that exist in curl have exactly the same semantic.
|
||||
Options that exist in curl have exactly the same semantics.
|
||||
|
||||
Options specified on the command line are defined for every Hurl file's entry.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user