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
Tests can be run with `pnpm test`or `pnpm test:watch` for the entire workspace or individual packages. `test:watch` keeps the process alive and runs tests as files are changed. If you want to run a single test, pass the path to the file as argument:
33
+
Tests can be run with `pnpm test`for the Vitest suite, `pnpm test:watch` for watch mode, or `pnpm test:e2e` for the Playwright end-to-end suite. If you want to run a single unit test, pass the path to the file as argument:
34
34
35
35
```
36
36
pnpm test path/to/my.test.ts
@@ -73,32 +73,9 @@ test("writes", async () => {
73
73
-[Vitest API](https://vitest.dev/api/)
74
74
-[Examples](https://vitest.dev/guide/#examples)
75
75
76
-
## Acceptance tests 🥒
76
+
## E2E tests
77
77
78
-
[Acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing) play an essential role in ensuring all the small pieces fit together to create user experiences.
79
-
They are defined as user stories which are a set of steps a user would take and the expectations they'd have while navigating through those steps.
80
-
81
-
```feature
82
-
Scenario: I create a new app with pnpm
83
-
Given I have a working directory
84
-
When I create an app named MyApp with pnpm as dependency manager
85
-
Then I have an app named MyApp with pnpm as dependency manager
86
-
```
87
-
Acceptance tests live under `packages/features` and implemented using [Cucumber](https://cucumber.io/). We create a working directory for every test that isolates the test from the rest. Moreover, the CLIs are invoked, configuring them to store global states in those temporary directories. That way, we prevent the global state from leaking into other tests and making them fail.
88
-
89
-
Each `.feature` file under `features/` group of scenarios has something in common (e.g. all scenarios related to app development). Steps are declared in Typescript files under `steps`. All the files in that directory or sub-directories are automatically loaded. We recommend keeping parity between those files and the features to quickly locate the steps.
90
-
91
-
### How to implement an acceptance test
92
-
93
-
1. Describe the scenario in a `.feature` file. Create a new one if you can't find a feature file your scenario fits into.
94
-
2. Implement the steps of your scenario.
95
-
3. Run the scenario with `FEATURE=path/to/scenario.feature:line yarn test`.
96
-
97
-
**Note** that we don't need to test all the user scenarios. Unlike unit tests, acceptance tests are slow. Focus on the user journeys that are most common and prefer larger but fewer scenarios over smaller but more.
98
-
99
-
> :bulb: Try to make them as generic as possible by using regular expressions when defining steps. That way, your steps can easily be reused by other scenarios.
100
-
101
-
> :bulb: If your scenario relies on a global state, for example, storing a file in the user's environment, adjust the implementation to control the state's location from the acceptance tests. This is extremely important to prevent flakiness.
78
+
End-to-end tests live under `packages/e2e` and are implemented using [Playwright](https://playwright.dev/). They test full user journeys by invoking the CLI and verifying outputs. Run them with `pnpm test:e2e`.
102
79
103
80
## Github Actions
104
81
Before being able to marge a PR, it must pass all CI checks executed in Github Actions.
0 commit comments