Skip to content

Commit 92216a3

Browse files
mitoyarzunacywatson
authored andcommitted
Add testing docs (#439)
* Add testing docs * Update
1 parent b5e36c6 commit 92216a3

File tree

3 files changed

+43
-1
lines changed

3 files changed

+43
-1
lines changed

.husky/pre-commit

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
#!/bin/sh
22
. "$(dirname "$0")/_/husky.sh"
33

4-
lint-staged
4+
npx lint-staged

README.md

+1
Original file line numberDiff line numberDiff line change
@@ -82,6 +82,7 @@ function Editor() {
8282
## Documentation
8383

8484
- [How Outline was designed](/docs/design.md)
85+
- [Testing](/docs/testing.md)
8586

8687
## Contributing
8788

docs/testing.md

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# Testing
2+
3+
Outline relies on tests to ensure that changes don't break anything, using a mix of unit and end-to-end tests.
4+
5+
## Unit tests
6+
7+
We use Jest to run unit tests in core (`outline` package). The goal is to have a well tested API, enabling us to add or modify features without breaking it.
8+
9+
To run the tests use:
10+
11+
```
12+
npm run test-unit
13+
```
14+
15+
Unit tests can be found in [this directory](/packages/outline/src/__tests__).
16+
17+
## End-to-end (E2E) tests
18+
19+
We use [Playwright](https://playwright.dev/) for running E2E tests in Chromium, Firefox and WebKit.
20+
21+
These tests run in the `outline-playground` package and are divided into proactive and reactive tests (`e2e` and `regression` directories).
22+
23+
The goal for this type of test is to validate the behavior of Outline in a browser, without necessarily knowing how the internals work.
24+
25+
To run E2E tests use:
26+
27+
```
28+
npm run start &
29+
npm run test-e2e:chromium # or :firefox, :webkit
30+
```
31+
32+
E2E tests can be found in [this directory](/packages/outline-playground/__tests__)
33+
34+
## General guidelines
35+
36+
When writing tests, please follow these practices:
37+
38+
- New features must include tests.
39+
- No test is too small or too big to be included. If it can break, add a test.
40+
- Do not merge pull requests with failing tests, this can block other people and releases.
41+
- Be mindful with your abstractions: sometimes it's convenient to create abstractions/utils to make test files smaller and less repetitive. Please make sure that they are simple and easy to follow.

0 commit comments

Comments
 (0)