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: platform/guardian-test/getting-started/installation.md
+5-1Lines changed: 5 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,11 @@ You can install GuardianTest using either npm or yarn:
41
41
42
42
At your repo's top-level directory create a file called `playwright.config.ts`.
43
43
44
-
If you already are using Playwright and already have a `playwright.config.ts`, just add `/.*gui\.(js|ts|mjs)/` to the `testMatch` entry to make sure Playwright recognizes our tests.
44
+
If you already are using Playwright and already have a `playwright.config.ts:`
45
+
46
+
* Add `/.*gui\.(js|ts|mjs)/` to the `testMatch` entry to make sure Playwright recognizes our tests
Performing interactions involves two pieces. 
23
+
Performing interactions involves two pieces.
24
24
25
25
* The locator of the object to interact with (for more information, check out the [Playwright Locators API documentation](https://playwright.dev/docs/locators)).
26
-
* The action to take. 
26
+
* The action to take.
27
27
28
28
By default Playwright waits for an element to be actionable before attempting to perform an action.
29
29
@@ -46,8 +46,6 @@ Playwright has a robust suite of actions built into the Locator API, the most co
46
46
|`locator.press()`| Press a single key |
47
47
|`locator.selectOption()`| Select on option from a drop down |
48
48
49
-
50
-
51
49
### Making General Assertions
52
50
53
51
Playwright natively includes test assertions by way of an `expect` function. For more information on the available functionality of `expect`, check out the [Playwright Assertions documentation](https://playwright.dev/docs/test-assertions).
@@ -74,8 +72,6 @@ There are also many async assertions which wait until the expected condition is
74
72
|`expect(page).toHaveTitle()`| Assert that the page has a certain title |
75
73
|`expect(page).toHaveURL()`| Assert that the page has a certain URL |
76
74
77
-
78
-
79
75
### Using Hooks
80
76
81
77
You can use test hooks to define groups of tests, or hooks like `test.beforeAll`, `test.beforeEach`, `test.afterAll`, and `test.afterEach` to perform reused sets of actions before/after each test or as setup/teardown for test suites. For more information visit the [Playwright Test Hooks documentation](https://playwright.dev/docs/api/class-test).
There are eight phases to writing your first GuardianUI end-to-end test:
123
114
124
115
1. Forked network initialization
125
116
2. Navigation to the dApp
126
-
3. Wallet initialization
127
-
4. Wallet state mocking
128
-
5. Wallet connection
129
-
6. Performing actions within the dApp
130
-
7. Transaction submission and verification
131
-
8. Stop the forked network
132
-
133
-
117
+
3. Wallet state mocking
118
+
4. Wallet connection
119
+
5. Performing actions within the dApp
120
+
6. Transaction submission and verification
134
121
135
122
### Phase 1: Forked Network Initialization
136
123
137
-
In order to set network state and perform network interactions without expending real tokens, every test that plans to interact with a live network needs to begin by initializing a forked network.
124
+
In order to set network state and perform network interactions without expending real tokens, every test that plans to interact with a live network needs to begin by initializing a forked network. Within this call you can specify the network you wish to fork using its chain ID, and optionally what block number you want to fork at (if you don't specify a block it runs at the latest). We recommend pinning to a block as it increases deterministicness of the tests.
138
125
139
126
<preclass="language-typescript"><codeclass="lang-typescript">import { test } from "@guardianui/test";
140
127
@@ -148,7 +135,7 @@ test.describe("Olympus Example Suite", () => {
148
135
});
149
136
</code></pre>
150
137
151
-
138
+
###
152
139
153
140
### Phase 2: Navigation To The dApp
154
141
@@ -169,33 +156,9 @@ test.describe("Olympus Example Suite", () => {
169
156
});
170
157
</code></pre>
171
158
159
+
###
172
160
173
-
174
-
### Phase 3: Wallet Initialization
175
-
176
-
In order for the test to behave correctly and consistently, you will need to initialize the injected wallet with the chain ID of the network it should be connected to.
177
-
178
-
<preclass="language-typescript"><codeclass="lang-typescript">import { test } from "@guardianui/test";
<strong> // Initialize wallet to connect to Ethereum mainnet (chain ID 1)
189
-
</strong><strong> await gui.initializeWallet(1);
190
-
</strong>
191
-
// Complete the rest of the test
192
-
});
193
-
});
194
-
</code></pre>
195
-
196
-
197
-
198
-
### Phase 4: Wallet State Mocking
161
+
### Phase 3: Wallet State Mocking
199
162
200
163
The test wallet injected into the browser during these tests is empty by default. We can provide it with gas tokens, ERC20 tokens, and set allowances in a few quick lines.
201
164
@@ -209,9 +172,6 @@ test.describe("Olympus Example Suite", () => {
@@ -226,13 +186,13 @@ test.describe("Olympus Example Suite", () => {
226
186
});
227
187
</code></pre>
228
188
189
+
###
229
190
230
-
231
-
### Phase 5: Wallet Connection
191
+
### Phase 4: Wallet Connection
232
192
233
193
The wallet connection flow will vary slightly from dApp to dApp, but usually requires locating a **"Connect Wallet"** button, and then selecting the **"Metamask"** option in an ensuing modal. While our wallet is not actually Metamask, it is surfaced to apps in a way that looks like Metamask to avoid issues where sites may not have an option to select an injected wallet.
234
194
235
-
To get a sense of what to write in the test, manually go to your live application and identify the visual and textual elements you need to click to go from the not-connected state to the connected state. Use the "inspect element" tool in browsers to help with this. 
195
+
To get a sense of what to write in the test, manually go to your live application and identify the visual and textual elements you need to click to go from the not-connected state to the connected state. Use the "inspect element" tool in browsers to help with this.
236
196
237
197
See examples in our [test examples](https://app.gitbook.com/o/aEzOvP1ODgbzLwqZ2irE/s/6blK04TyOYOkA5ZEQW4b/end-to-end-testing/test-examples) section.
238
198
@@ -246,9 +206,6 @@ test.describe("Olympus Example Suite", () => {
@@ -274,9 +231,9 @@ test.describe("Olympus Example Suite", () => {
274
231
});
275
232
</code></pre>
276
233
234
+
###
277
235
278
-
279
-
### Phase 6: Performing Actions Within the dApp
236
+
### Phase 5: Performing Actions Within the dApp
280
237
281
238
This will vary drastically from dApp to dApp, but generally requires identifying elements on the web page based on class or ID selectors and clicking or entering information into them.
282
239
@@ -292,9 +249,6 @@ test.describe("Olympus Example Suite", () => {
@@ -333,9 +287,9 @@ test.describe("Olympus Example Suite", () => {
333
287
});
334
288
</code></pre>
335
289
290
+
###
336
291
337
-
338
-
### Phase 7: Transaction Submission and Verification
292
+
### Phase 6: Transaction Submission and Verification
339
293
340
294
One of the primary novel behaviors of the GuardianTest framework is its ability to validate information around network transactions following a site interaction such as a button click. Doing this requires two pieces of information:
341
295
@@ -354,9 +308,6 @@ test.describe("Olympus Example Suite", () => {
GuardianUI tests run in sequence to avoid port collisions when creating and using Anvil forks. However, the fork isn't torn down at the end of a test by default, so to end the test you need to specify that the fork is no longer needed.
405
-
406
-
<preclass="language-typescript"><codeclass="lang-typescript">import { test } from "@guardianui/test";
0 commit comments