mirror of
https://github.com/zadam/trilium.git
synced 2026-01-18 13:22:14 +01:00
chore(docs): restructure developer guide for monorepo
This commit is contained in:
Binary file not shown.
|
After Width: | Height: | Size: 9.7 KiB |
@@ -0,0 +1,38 @@
|
||||
# Running tests
|
||||
## First-time run
|
||||
|
||||
Before starting Playwright, it has to be installed locally via:
|
||||
|
||||
```
|
||||
npx playwright install
|
||||
```
|
||||
|
||||
## Starting the integration test server
|
||||
|
||||
There are two types of integration test servers:
|
||||
|
||||
* `npm run integration-mem-db` will run a server with dev mode disabled.
|
||||
* This is usually what the end user will see when accessing a server instance.
|
||||
* It will not test the Electron/desktop side of the application.
|
||||
* Changes to the public scripts will not take effect until running `npm run webpack`.
|
||||
* `npm run integration-mem-db-dev` will run a server with dev mode enabled.
|
||||
* This is usually what a dev sees when running `npm run start-server`.
|
||||
* The difference with the production one is that the assets are loaded directly from files and as such it does not require `npm run webpack` to see changes.
|
||||
|
||||
Either options will open up a server on [localhost:8082](http://localhost:8082) that can be accessed either manually via the browser or via Playwright.
|
||||
|
||||
When asked for a password, the password is `demo1234`.
|
||||
|
||||
## Starting the interactive test runner
|
||||
|
||||
After starting the integration test server, to run the Playwright UI, run in the terminal:
|
||||
|
||||
```
|
||||
npx playwright test --ui
|
||||
```
|
||||
|
||||
It is also possible to run the interactive code generator instead:
|
||||
|
||||
```
|
||||
npx playwright codegen
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
# Setting up authentication
|
||||
There is a setup test that stores the authentication token so that it can be reused throughout all the tests.
|
||||
|
||||
If tests fail due to being stuck on login, then it must be run.
|
||||
|
||||
To run it manually press “all” near the “Status:” text on top-left of the window
|
||||
|
||||
<figure class="image"><img src="1_Setting up authentication_.png"></figure>
|
||||
|
||||
Then check “setup” and look for `auth.setup.ts` and press its corresponding Run button:
|
||||
|
||||
<figure class="image"><img src="Setting up authentication_.png"></figure>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
@@ -0,0 +1,34 @@
|
||||
# Test database
|
||||
The integration tests do not use the same database as `npm run start-server`. Instead, the database is located `integration-tests/db/document.db`.
|
||||
|
||||
## In-memory database
|
||||
|
||||
Even though we are running our own database, there is still the problem of one test affecting the content for the others or accidentally removing important test notes.
|
||||
|
||||
To avoid this, the integration test server (run via `integration-mem-db`) loads the database from `integration-test` into memory and operates from there. That means that any changes done on the integration test server (port 8082) will not be persisted between restarts of the server.
|
||||
|
||||
Another benefit of having the database in memory for tests is that they can run in parallel without the risk on interfering with each other.
|
||||
|
||||
## How to make changes to the database
|
||||
|
||||
As mentioned previously, the database itself can be edited manually in order to add content that is relevant to the tests.
|
||||
|
||||
In order to do so, run a separate integration test server with:
|
||||
|
||||
```
|
||||
npm run integration-edit-db
|
||||
```
|
||||
|
||||
This will open up a server on port 8081 which can be used to alter the integration test DB. After finishing the desired changes, it's ideal to close the server to prevent any interferences with further running of tests.
|
||||
|
||||
## The database is tracked by Git
|
||||
|
||||
This is intentional, meaning that any change to the database will mark the file as changed in Git as well. Some tests require a specific note and it would be too wasteful to have to recreate it via Playwright each time. Instead the content is added manually and then the tests operate directly on the said notes.
|
||||
|
||||
In order to make the database easier to track, SQLite WAL was disabled but only for the integration database. This means that only the `.db` file is present and needs to be committed.
|
||||
|
||||
## Cleaning up the database
|
||||
|
||||
It's recommended to clean up any deleted notes to avoid unnecessary changes being committed. To do so go to Recent Changes in the launcher and select “Erase deleted notes now”.
|
||||
|
||||
It's also a good idea to go to Options → Advanced → Vacuum database to clean up it.
|
||||
Reference in New Issue
Block a user