You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/quick-start.md
+21-15Lines changed: 21 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,40 +8,46 @@ Prerequisite: [Setup **CHKware**](/docs/setup) to continue
8
8
9
9
:::
10
10
11
-
### A real business story
11
+
### 1. A business story
12
12
13
-
DummyJSON service a JSON response faker for API. Let's think of a business case based on the [listed APIs](https://dummyjson.com/docs).
13
+
DummyJSON service a JSON request / response faker for API. Let's think of a business case based on the [listed APIs](https://dummyjson.com/docs).
14
14
15
-
#### Business scenario:
15
+
#### Business case:
16
16
17
17
User should be able to add a post on DummyJSON service.
18
18
19
19
#### Test cases:
20
20
21
-
Suppose our webapp have a page to add a new post. This page also shows some user information. Let's imagine the API test workflow for this page.
21
+
Suppose our web application has a page to add a new post. This page also shows some user information.
22
+
23
+
Let's assume the API test workflow for this page looks like following:
22
24
23
25
1. User is able to login. API response have a bearer *access_token*.
24
26
2. User is able to get *self* or *me* URL to show user information on page.
25
27
3. User is able to create a post using that bearer *access_token*.
26
28
27
-
### Test implementation
29
+
Let's create API test cases for these steps.
30
+
31
+
### 2. Test implementation
28
32
29
33
To implement the above test cases we need to be able to fetch an API response. Fetch multiple different APIs in a flow. Let's do in with *CHKware*.
30
34
31
35
#### Prepare for the project.
32
36
33
-
- Create a directory in anywhere in your system and give it a meaningful name.
34
-
- Now open the console terminal where `chk` command is install. Follow setup steps if it hasn't been done already.
35
-
- Go to the directory in console using
37
+
- Create a directory called `my-api-project-tests` in anywhere in your system. You can give it any meaningful name.
38
+
- Now open the console terminal. Please make sure `chk` command is installed globally. Follow [setup steps](./setup.md) if it hasn't been done already.
39
+
- Go to the `my-api-project-tests` directory in console using
40
+
36
41
```shell
37
-
cd[DIRECTORY]
42
+
cdpath/to/my-api-project-tests
38
43
```
39
44
40
45
#### Login to get bearer *access_token*
41
46
42
-
- Create a file called `req-login.chk`. File name has no special significance. Open `req-login.chk` file, and add following:
47
+
- Create a file called `req-login.chk`.
48
+
- Open `req-login.chk` file in your favourite text editor, and add following:
This file is called *HTTP specification* or *HTTP spec* file in *CHKware*. This file holds configuration to call an URL.
70
+
This file is called *HTTP specification* or *HTTP spec* file in *CHKware*. This file holds configuration to make one HTTP request.
65
71
66
72
With `request:` node, we define what to request, and with `expose:` section we mention what to return. In this case the HTTP response body that was received.
67
73
@@ -72,7 +78,7 @@ expose:
72
78
73
79
- Create a file called `req-user-me.chk`. File name has no special significance. Open `req-user-me.chk` file, and add following:
Copy file name to clipboardExpand all lines: docs/references/assertions.md
+53-45Lines changed: 53 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,72 +4,80 @@ title: Assertions
4
4
5
5
Assertions are integral part of [_Validate specification_](/docs/references/validate-spec).
6
6
7
-
Assertions are used for the validation of specific data point. Asserts are written in _validate specification_.
7
+
Assertions are used for the validation of specific data point. Asserts are written in _validate specification. It looks like following:
8
+
9
+
```yml {6-11}
10
+
version: default:validate:0.7.2
11
+
12
+
data:
13
+
code: 200
14
+
15
+
asserts:
16
+
- type: Equal
17
+
actual: <% _data.code %>
18
+
expected: 200
19
+
msg_pass: 'Response was successful'
20
+
msg_fail: 'Response was unsuccessful'
21
+
22
+
- # [assertItem]
23
+
```
8
24
9
25
## Assert items
10
26
_CHKware_ have a collection of built-in assert items. Assertion item object have following components:
11
27
12
-
-`type` Type of assertion to be executed or the assertion key.
28
+
-`type` Type of assertion to be executed or the assertion key.[See here](#assert-types)
13
29
14
30
-`actual` Actual data point for validation. Variables or data can be used.
15
31
16
32
-`expected` Expected data point for validation. Variables or data can be used. Most assert item have `expected` alternative to `other`. Both can not exist in same assert item at the same time.
17
33
18
34
-`other` Other data point for compare. Variables or data can be used. Some assert item have `other` alternative to `expected`. Both can not exist in same assert item at the same time.
19
35
20
-
-`format` Format of a date. Only supported with [Date assert](#date) items
21
-
22
-
:::tip
23
-
24
-
Supports these [format code](https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes).
25
-
26
-
:::
27
-
28
-
-`msg_pass` An alternative message to display on success.
29
-
30
-
:::tip
31
-
32
-
It is possible to pass formatted string to `msg_pass`. Following values are supported:
- type_actual : Type of the actual given on spec file
36
-
- type_expected : Type of the expected given on spec file
37
-
- value_expected : Value of the expected given on spec file
38
-
- value_actual : Value of the actual after cast conversion
39
-
- value_actual_given : Value of the actual given on spec file
40
-
- value_actual_b4_cast : Value of the actual before cast conversion
41
-
42
-
E.g: "actual `{type_actual}({value_actual})` is equal to expected `{type_expected}({value_expected})`"
43
-
44
-
:::
45
-
46
-
-`msg_fail` An alternative message to display on failure
36
+
-`format` Format of a date. Only supported with [`Date` assert](#date) items. Supports these [format code](https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes).
47
37
48
-
:::tip
38
+
-`msg_pass` An alternative message to display on success. It is possible to pass formatted string to `msg_pass`.
49
39
50
-
It is possible to pass formatted string to `msg_fail`. Following values are supported:
- type_actual : Type of the actual given on spec file
63
+
- type_expected : Type of the expected given on spec file
64
+
- value_expected : Value of the expected given on spec file
65
+
- value_actual : Value of the actual after cast conversion
66
+
- value_actual_given : Value of the actual given on spec file
67
+
- value_actual_b4_cast : Value of the actual before cast conversion
68
+
69
+
---
70
+
E.g: "actual `{type_actual}({value_actual})` is not equal to expected `{type_expected}({value_expected})`"
67
71
68
-
It is possible to cast type of `actual` value before comparison with `expected` with `cast_actual_to`.
72
+
</details>
69
73
70
-
These types are supported: `int_or_float`, `int`, `float`, `bool`, `none`, `map`, `list`, `str`, `auto`
74
+
-`cast_actual_to` Cast data to the type before assertion. It is possible to cast type of `actual` value before comparison with `expected` with variables.
75
+
76
+
<details>
77
+
<summary>Supported values are:</summary>
71
78
72
-
:::
79
+
These types are supported: `int_or_float`, `int`, `float`, `bool`, `none`, `map`, `list`, `str`, `auto`
80
+
</details>
73
81
74
82
<details>
75
83
<summary>All supported nodes in assert item</summary>
0 commit comments