mockaton 8.6.0 → 8.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +44 -27
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -5,50 +5,60 @@
|
|
|
5
5
|
|
|
6
6
|
## Mock your APIs, Enhance your Development Workflow
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
development and testing
|
|
8
|
+
Welcome to developer experience tooling! Mockaton is here to help
|
|
9
|
+
make your frontend development and testing easier—and a lot more fun.
|
|
10
10
|
|
|
11
|
-
With Mockaton you don’t need to write code for wiring your mocks. Instead,
|
|
12
|
-
|
|
13
|
-
|
|
11
|
+
With Mockaton you don’t need to write code for wiring your mocks. Instead, just
|
|
12
|
+
place your mocks in a directory and let Mockaton do the rest. It will automatically
|
|
13
|
+
scan the directory for filenames that follow a convention similar to the URL paths.
|
|
14
|
+
|
|
15
|
+
For example, for this route `/api/user/1234`, the mock filename would be:
|
|
14
16
|
```
|
|
15
17
|
my-mocks-dir/api/user/[user-id].GET.200.json
|
|
16
18
|
```
|
|
17
19
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
+
And hey, no need to mock everything. If you don’t have a mock for
|
|
21
|
+
a certain API, Mockaton can fallback to your real backend. Just
|
|
22
|
+
type your backend address in the **Fallback Backend** field.
|
|
20
23
|
|
|
21
|
-
|
|
24
|
+
And there’s one more cool thing—you can collect those responses
|
|
25
|
+
by clicking the **Save Mocks** checkbox. Those mocks will
|
|
26
|
+
be saved to your `config.mocksDir` following the filename convention.
|
|
22
27
|
|
|
23
|
-
## Scraping Mocks
|
|
24
|
-
You can save mocks following the filename convention
|
|
25
|
-
for the routes that reached your `proxyFallback` with:
|
|
26
28
|
|
|
27
|
-
|
|
29
|
+
## Multiple Mock Variants
|
|
28
30
|
|
|
31
|
+
You can have many mocks for any route. For example, you might
|
|
32
|
+
want different mocks with different response status codes
|
|
33
|
+
(like triggering errors). Here are a couple of ways to do it:
|
|
29
34
|
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
- __Comment__ on the filename, which is anything within parentheses.
|
|
34
|
-
- e.g. `api/login(locked out user).POST.423.json`
|
|
35
|
+
### Adding comments in filenames
|
|
36
|
+
Want to mock a locked-out user or an invalid login attempt? You
|
|
37
|
+
can just add a comment to the filename in parentheses. For example:
|
|
35
38
|
|
|
39
|
+
`api/login(locked out user).POST.423.json`
|
|
40
|
+
|
|
41
|
+
### Different response status code
|
|
42
|
+
For instance, you can have mocks with a `4xx` or `5xx` status code for triggering
|
|
43
|
+
error responses. Or with a `204` (No Content) for testing empty collections.
|
|
36
44
|
|
|
37
|
-
## Dashboard
|
|
38
45
|
|
|
39
|
-
|
|
40
|
-
|
|
46
|
+
## Dashboard
|
|
47
|
+
In the dashboard you can select a mock variant for a particular route, among
|
|
48
|
+
other features such as delaying responses, or triggering an autogenerated
|
|
49
|
+
`500` (Internal Server Error). Nonetheless, there’s a programmatic API,
|
|
41
50
|
which is handy for setting up tests (see **Commander API** below).
|
|
42
51
|
|
|
43
52
|
<picture>
|
|
44
|
-
<source media="(prefers-color-scheme: light)" srcset="./pixaton-tests/pic-for-readme.
|
|
45
|
-
<source media="(prefers-color-scheme: dark)" srcset="./pixaton-tests/pic-for-readme.
|
|
46
|
-
<img alt="Mockaton Dashboard" src="./pixaton-tests/pic-for-readme.
|
|
53
|
+
<source media="(prefers-color-scheme: light)" srcset="./pixaton-tests/pic-for-readme.vp860x800.light.gold.png">
|
|
54
|
+
<source media="(prefers-color-scheme: dark)" srcset="./pixaton-tests/pic-for-readme.vp860x800.dark.gold.png">
|
|
55
|
+
<img alt="Mockaton Dashboard" src="./pixaton-tests/pic-for-readme.vp860x800.light.gold.png">
|
|
47
56
|
</picture>
|
|
48
57
|
|
|
49
58
|
|
|
59
|
+
|
|
50
60
|
## Basic Usage
|
|
51
|
-
`tsx` is only needed if you want to write mocks in TypeScript
|
|
61
|
+
`tsx` is only needed if you want to write mocks in TypeScript.
|
|
52
62
|
```sh
|
|
53
63
|
npm install mockaton tsx --save-dev
|
|
54
64
|
```
|
|
@@ -72,7 +82,12 @@ node --import=tsx my-mockaton.js
|
|
|
72
82
|
|
|
73
83
|
## Running the demo app (Vite)
|
|
74
84
|
|
|
75
|
-
This is a minimal React + Vite + Mockaton app.
|
|
85
|
+
This is a minimal React + Vite + Mockaton app. It’s mainly a list of
|
|
86
|
+
colors, which contains all of their possible states. For example,
|
|
87
|
+
permutations for out-of-stock, new-arrival, and discontinued.
|
|
88
|
+
|
|
89
|
+
Also, if you select the **Admin User** from the Mockaton dashboard,
|
|
90
|
+
the color cards will have a Delete button as well.
|
|
76
91
|
|
|
77
92
|
```sh
|
|
78
93
|
git clone https://github.com/ericfortis/mockaton.git
|
|
@@ -82,9 +97,11 @@ npm run mockaton
|
|
|
82
97
|
npm run start
|
|
83
98
|
```
|
|
84
99
|
|
|
85
|
-
By the way, that directory has
|
|
100
|
+
By the way, that directory has scripts for opening Mockaton and Vite in one command.
|
|
101
|
+
|
|
102
|
+
The app looks like this:
|
|
86
103
|
|
|
87
|
-
<img src="./demo-app-vite/README-screenshot.png" alt="Mockaton Demo App Screenshot"
|
|
104
|
+
<img src="./demo-app-vite/README-screenshot.png" alt="Mockaton Demo App Screenshot" width="580" />
|
|
88
105
|
|
|
89
106
|
|
|
90
107
|
## Use Cases
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"name": "mockaton",
|
|
3
3
|
"description": "A deterministic server-side for developing and testing frontend clients",
|
|
4
4
|
"type": "module",
|
|
5
|
-
"version": "8.6.
|
|
5
|
+
"version": "8.6.1",
|
|
6
6
|
"main": "index.js",
|
|
7
7
|
"types": "index.d.ts",
|
|
8
8
|
"license": "MIT",
|
|
@@ -16,6 +16,6 @@
|
|
|
16
16
|
},
|
|
17
17
|
"optionalDependencies": {
|
|
18
18
|
"pixaton": ">=1.0.2",
|
|
19
|
-
"puppeteer": ">=
|
|
19
|
+
"puppeteer": ">=24.1.1"
|
|
20
20
|
}
|
|
21
21
|
}
|