ComputerSurge/lazygit
3
0
Fork 0
Code Pull Requests 1 Activity

better CLI interface

Browse Source
This commit is contained in:
Jesse Duffield
2022-08-14 14:33:44 +10:00
parent 349a7d2453
commit 5173d7f5e1
13 changed files with 287 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
pkg/integration/README.md
View File

@@ -37,21 +37,21 @@ If you find yourself doing something frequently in a test, consider making it a
There are three ways to invoke a test:
1. go run pkg/integration/cmd/runner/main.go [<testname>...]
2. go run pkg/integration/cmd/tui/main.go
3. go test pkg/integration/go_test.go
1. go run cmd/integration_test/main.go cli [<testname>...]
2. go run cmd/integration_test/main.go tui
3. go test pkg/integration/clients/go_test.go
The first, the test runner, is for directly running a test from the command line. If you pass no arguments, it runs all tests.
The second, the TUI, is for running tests from a terminal UI where it's easier to find a test and run it without having to copy it's name and paste it into the terminal. This is the easiest approach by far.
The third, the go-test command, intended only for use in CI, to be run along with the other `go test` tests. This runs the tests in headless mode so there's no visual output.
The name of a test is based on its path, so the name of the test at `pkg/integration/tests/commit/new_branch.go` is commit/new_branch. So to run it with our test runner you would run `go run pkg/integration/cmd/runner/main.go commit/new_branch`.
The name of a test is based on its path, so the name of the test at `pkg/integration/tests/commit/new_branch.go` is commit/new_branch. So to run it with our test runner you would run `go run cmd/integration_test/main.go cli commit/new_branch`.
You can pass the KEY_PRESS_DELAY env var to the test runner in order to set a delay in milliseconds between keypresses, which helps for watching a test at a realistic speed to understand what it's doing. Or in the tui you can press 't' to run the test with a pre-set delay.
### Snapshots
At the moment (this is subject to change) each test has a snapshot repo created after running for the first time. These snapshots live in `test/integration_new`, in folders named 'expected' (alongside the 'actual' folders which contain the resulting repo from the last test run). Whenever you run a test, the resultant repo will be compared against the snapshot repo and if they're different, you'll be asked whether you want to update the snapshot. If you want to update a snapshot without being prompted you can pass MODE=updateSnapshot to the test runner.
At the moment (this is subject to change) each test has a snapshot repo created after running for the first time. These snapshots live in `test/integration_new`, in folders named 'expected' (alongside the 'actual' folders which contain the resulting repo from the last test run). Whenever you run a test, the resultant repo will be compared against the snapshot repo and if they're different, you'll be asked whether you want to update the snapshot. If you want to update a snapshot without being prompted you can pass MODE=update to the test runner.
### Sandbox mode