go/lazygit
1
0
Fork 0
mirror of https://github.com/jesseduffield/lazygit.git synced 2025-04-07 07:19:57 +02:00
Code Issues Releases Activity

update readme

Browse Source
This commit is contained in:
Jesse Duffield 2022-12-26 17:51:19 +11:00
parent 09db4c4397
commit 8c89069965
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
pkg/integration/README.md
View File

@ -39,8 +39,12 @@ The run step has four arguments passed in:
### Tips
#### Handle most setup in the `shell` part of the test
Try to do as much setup work as possible in your setup step. For example, if all you're testing is that the user is able to resolve merge conflicts, create the merge conflicts in the setup step. On the other hand, if you're testing to see that lazygit can warn the user about merge conflicts after an attempted merge, it's fine to wait until the run step to actually create the conflicts. If the run step is focused on the thing you're trying to test, the test will run faster and its intent will be clearer.
#### Assert after input
Use assertions to ensure that lazygit has processed all your keybindings so far. Each time you press a key, something should happen on the screen, so you should assert that that thing has happened. This means we won't get into trouble from keys being entered two quickly because at each stage we ensure the key has been processed. This also makes tests more readable because they help explain what we expect to be happening on-screen. For example:
```go
@ -48,6 +52,10 @@ input.Press(keys.Files.CommitChanges)
assert.InCommitMessagePanel()
```
Note that there are some `input` methods that have assertions baked in, such as the `SwitchToView` methods.
#### Create helper functions for (very) frequently used test logic
If you find yourself doing something frequently in a test, consider making it a method in one of the helper arguments. For example, instead of calling `input.PressKey(keys.Universal.Confirm)` in 100 places, it's better to have a method `input.Confirm()`. This is not to say that everything should be made into a method on the input struct: just things that are particularly common in tests.
Also, given how often we need to select a menu item or type into a prompt panel, there are some helper functions for that. For example: