mirror of
1
Fork 0
forgejo/tests/e2e
silverwind 12b199c5e5
Enable more `revive` linter rules (#30608)
Noteable additions:

- `redefines-builtin-id` forbid variable names that shadow go builtins
- `empty-lines` remove unnecessary empty lines that `gofumpt` does not
remove for some reason
- `superfluous-else` eliminate more superfluous `else` branches

Rules are also sorted alphabetically and I cleaned up various parts of
`.golangci.yml`.

(cherry picked from commit 74f0c84fa4245a20ce6fb87dac1faf2aeeded2a2)

Conflicts:
	.golangci.yml
	apply the linter recommendations to Forgejo code as well
2024-04-28 15:39:00 +02:00
..
README.md [CHORE] Remove Microsoft SQL Server Support 2024-04-05 23:37:36 +02:00
debugserver_test.go [CHORE] Remove `println` 2024-04-12 13:36:31 +02:00
e2e_test.go Enable more `revive` linter rules (#30608) 2024-04-28 15:39:00 +02:00
example.test.e2e.js [Port] gitea#29982 Introduce `.secondary-nav` and handle `.page-content` spacing universally 2024-03-28 16:43:09 +01:00
explore.test.e2e.js Playwright e2e test for taborder 2024-03-12 02:23:29 +01:00
right-settings-button.test.e2e.js Move settings button back to the right in repo and org header 2024-04-26 23:59:08 +02:00
utils_e2e.js [Port] gitea#29982 Introduce `.secondary-nav` and handle `.page-content` spacing universally 2024-03-28 16:43:09 +01:00
utils_e2e_test.go Refactor tests (#26464) 2023-08-12 16:30:16 +00:00

README.md

End to end tests

E2e tests largely follow the same syntax as integration tests. Whereas integration tests are intended to mock and stress the back-end, server-side code, e2e tests the interface between front-end and back-end, as well as visual regressions with both assertions and visual comparisons. They can be run with make commands for the appropriate backends, namely:

make test-sqlite
make test-pgsql
make test-mysql

Make sure to perform a clean front-end build before running tests:

make clean frontend

Install playwright system dependencies

npx playwright install-deps

Run all tests via local act_runner

act_runner exec -W ./.github/workflows/pull-e2e-tests.yml --event=pull_request --default-actions-url="https://github.com" -i catthehacker/ubuntu:runner-latest

Run sqlite e2e tests

Start tests

make test-e2e-sqlite

Run MySQL e2e tests

Setup a MySQL database inside docker

docker run -e "MYSQL_DATABASE=test" -e "MYSQL_ALLOW_EMPTY_PASSWORD=yes" -p 3306:3306 --rm --name mysql mysql:latest #(just ctrl-c to stop db and clean the container)
docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --rm --name elasticsearch elasticsearch:7.6.0 #(in a second terminal, just ctrl-c to stop db and clean the container)

Start tests based on the database container

TEST_MYSQL_HOST=localhost:3306 TEST_MYSQL_DBNAME=test TEST_MYSQL_USERNAME=root TEST_MYSQL_PASSWORD='' make test-e2e-mysql

Run pgsql e2e tests

Setup a pgsql database inside docker

docker run -e "POSTGRES_DB=test" -p 5432:5432 --rm --name pgsql postgres:latest #(just ctrl-c to stop db and clean the container)

Start tests based on the database container

TEST_PGSQL_HOST=localhost:5432 TEST_PGSQL_DBNAME=test TEST_PGSQL_USERNAME=postgres TEST_PGSQL_PASSWORD=postgres make test-e2e-pgsql

Running individual tests

Example command to run example.test.e2e.js test file:

Note: unlike integration tests, this filtering is at the file level, not function

For SQLite:

make test-e2e-sqlite#example

For PostgreSQL databases(replace mysql to pgsql):

TEST_MYSQL_HOST=localhost:1433 TEST_MYSQL_DBNAME=test TEST_MYSQL_USERNAME=sa TEST_MYSQL_PASSWORD=MwantsaSecurePassword1 make test-e2e-mysql#example

Visual testing

Although the main goal of e2e is assertion testing, we have added a framework for visual regress testing. If you are working on front-end features, please use the following:

  • Check out main, make clean frontend, and run e2e tests with VISUAL_TEST=1 to generate outputs. This will initially fail, as no screenshots exist. You can run the e2e tests again to assert it passes.
  • Check out your branch, make clean frontend, and run e2e tests with VISUAL_TEST=1. You should be able to assert you front-end changes don't break any other tests unintentionally.

VISUAL_TEST=1 will create screenshots in tests/e2e/test-snapshots. The test will fail the first time this is enabled (until we get visual test image persistence figured out), because it will be testing against an empty screenshot folder.

ACCEPT_VISUAL=1 will overwrite the snapshot images with new images.