1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2025-02-03 13:21:56 +02:00

31 Commits

Author SHA1 Message Date
Jesse Duffield
8c716184c1 Set working directory in lazygit test command
We need to fetch our list of tests both outside of our test binary and within. We need
to get the list from within so that we can run the code that drives the test and runs
assertions. To get the list of tests we need to know where the root of the lazygit repo
is, given that the tests live in files under that root.

So far, we've used this GetLazyRootDirectory() function for that, but it assumes that
we're not in a test directory (it just looks for the first .git dir it can find). Because
we didn't want to properly fix this before, we've been setting the working directory of
the test command to the lazygit root, and using the --path CLI arg to override it when
the test itself ran. This was a terrible hack.

Now, we're passing the lazygit root directory as an env var to the integration test, so
that we can set the working directory to the actual path of the test repo; removing the
need to use the --path arg.
2024-01-12 19:59:31 +11:00
Jesse Duffield
aaecd6cc40 Add coverage arg for integration tests
This PR captures the code coverage from our unit and integration tests. At the
moment it simply pushes the result to Codacy, a platform that assists with
improving code health. Right now the focus is just getting visibility but I want
to experiment with alerts on PRs when a PR causes a drop in code coverage.

To be clear: I'm not a dogmatist about this: I have no aspirations to get to
100% code coverage, and I don't consider lines-of-code-covered to be a perfect
metric, but it is a pretty good heuristic for how extensive your tests are.

The good news is that our coverage is actually pretty good which was a surprise
to me!

As a conflict of interest statement: I'm in Codacy's 'Pioneers' program which
provides funding and mentorship, and part of the arrangement is to use Codacy's
tooling on lazygit. This is something I'd have been happy to explore even
without being part of the program, and just like with any other static analysis
tool, we can tweak it to fit our use case and values.

## How we're capturing code coverage

This deserves its own section. Basically when you build the lazygit binary you
can specify that you want the binary to capture coverage information when it
runs. Then, if you run the binary with a GOCOVERDIR env var, it will write
coverage information to that directory before exiting.

It's a similar story with unit tests except with those you just specify the
directory inline via `-test.gocoverdir`.

We run both unit tests and integration tests separately in CI, _and_ we run them
parallel with different OS's and git versions. So I've got each step uploading
the coverage files as an artefact, and then in a separate step we combine all
the artefacts together and generate a combined coverage file, which we then
upload to codacy (but in future we can do other things with it like warn in a PR
if code coverage decreases too much).

Another caveat is that when running integration tests, not only do we want to
obtain code coverage from code executed by the test binary, we also want to
obtain code coverage from code executed by the test runner. Otherwise, for each
integration test you add, the setup code (which is run by the test runner, not
the test binary) will be considered un-covered and for a large setup step it may
appear that your PR _decreases_ coverage on net. Go doesn't easily let you
exclude directories from coverage reports so it's better to just track the
coverage from both the runner and the binary.

The binary expects a GOCOVERDIR env var but the test runner expects a
test.gocoverdir positional arg and if you pass the positional arg it will
internally overwrite GOCOVERDIR to some random temp directory and if you then
pass that to the test binary, it doesn't seem to actually write to it by the
time the test finishes. So to get around that we're using LAZYGIT_GOCOVERDIR and
then within the test runner we're mapping that to GOCOVERDIR before running the
test binary. So they both end up writing to the same directory. Coverage data
files are named to avoid conflicts, including something unique to the process,
so we don't need to worry about name collisions between the test runner and the
test binary's coverage files. We then merge the files together purely for the
sake of having fewer artefacts to upload.

## Misc

Initially I was able to have all the instances of '/tmp/code_coverage' confined
to the ci.yml which was good because it was all in one place but now it's spread
across ci.yml and scripts/run_integration_tests.sh and I don't feel great about
that but can't think of a way to make it cleaner.

I believe there's a use case for running scripts/run_integration_tests.sh
outside of CI (so that you can run tests against older git versions locally) so
I've made it that unless you pass the LAZYGIT_GOCOVERDIR env var to that script,
it skips all the code coverage stuff.

On a separate note: it seems that Go's coverage report is based on percentage of
statements executed, whereas codacy cares more about lines of code executed, so
codacy reports a higher percentage (e.g. 82%) than Go's own coverage report
(74%).
2023-11-30 12:58:41 +11:00
Jesse Duffield
7e5f25e415 Use args struct for RunTests
There were too many position arguments
2023-11-29 11:39:10 +11:00
Stefan Haller
92e107f52d Use constant for WAIT_FOR_DEBUGGER env var 2023-09-28 10:03:53 +02:00
Stefan Haller
2f6a87df98 Build lazygit without optimizations and inlining when debugging
This makes the debugging experience better.
2023-09-28 10:03:53 +02:00
Stefan Haller
59cc6843e6 Print race detector logs after running a test with -race 2023-09-25 09:09:41 +02:00
Stefan Haller
f108fd2236 Support -race arg when running integration tests to turn on go's race detector
For the "cli" and "tui" modes of the test runner there's a "-race" parameter to
turn it on; for running tests on CI with go test, you turn it on by setting the
environment variable LAZYGIT_RACE_DETECTOR to a non-empty value.
2023-09-25 09:09:41 +02:00
Stefan Haller
c465b0f2ff Rename test/results to test/_results
This prevents commands like "go test ./..." from looking into it, and it
prevents VS Code's Problems panel from showing errors about the go files in that
folder.
2023-09-15 18:04:20 +02:00
Stefan Haller
b6c892a08a Provide a simple way to debug an integration test 2023-09-11 08:17:58 +02:00
Simon Whitaker
ed1547e0cb Add a Click() primitive to the integration test library 2023-08-07 15:10:28 +01:00
Jesse Duffield
0551f29de9 Test bare repos with dotfile setup 2023-08-07 22:21:23 +10:00
Jesse Duffield
c92ed07082 Appease linter 2023-08-02 08:32:57 +10:00
Stefan Haller
f4ada537d2 Remove mainBranch parameter from Shell.Init()
For older git versions we won't be able to support any other main branch than
"master", so hard-code that in Init.

This doesn't fix anything for older versions yet; see the next commit for that.
2023-07-10 15:09:17 +02:00
Jesse Duffield
c92e687d3b Fix focus issue when opening recent-repos menu at launch
I don't know why we were setting the initial context to CurrentSideContext
and not just CurrentContext in the first place. If there is no current context
in either case it'll default to the files context. So the only issue is if
we anticipated that some random context would be focused and we didn't want to
activate that. But I can't think of any situation where that would happen.
2023-06-07 18:27:18 +10:00
Jesse Duffield
63dc07fded Construct arg vector manually rather than parse string
By constructing an arg vector manually, we no longer need to quote arguments

Mandate that args must be passed when building a command

Now you need to provide an args array when building a command.
There are a handful of places where we need to deal with a string,
such as with user-defined custom commands, and for those we now require
that at the callsite they use str.ToArgv to do that. I don't want
to provide a method out of the box for it because I want to discourage its
use.

For some reason we were invoking a command through a shell when amending a
commit, and I don't believe we needed to do that as there was nothing user-
supplied about the command. So I've switched to using a regular command out-
side the shell there
2023-05-23 19:49:19 +10:00
Jesse Duffield
8a86de85c8 remove log call because it clutters test output 2023-04-30 13:19:53 +10:00
Stefan Haller
a304fed68c Add GitVersion field to NewIntegrationTestArgs
It can be used to specify which git versions a given test should or should not run on.
2023-04-15 08:36:03 +02:00
Jesse Duffield
f7e8b2dd71 cleanup integration test code 2023-02-26 12:54:13 +11:00
Jesse Duffield
7a3291a1f7 fix test 2023-02-12 18:12:01 +11:00
stk
b243f30f48 Disable ~/.gitconfig when running integration tests
A global ~/.gitconfig file can have influence on how integration tests behave;
in my case, I had the option "merge.conflictStyle" set to "diff3", which made
the integration test "cherry_pick_conflict" fail because the diff was different
from what the test expected.

Make this more robust by telling git to ignore the global config file when
running tests.
2023-02-07 17:26:45 +01:00
Jesse Duffield
c5050ecabd move shell into test driver 2022-12-27 21:47:37 +11:00
Jesse Duffield
b623ecf898 add helper functions for popups in tests 2022-12-24 19:15:59 +11:00
Jesse Duffield
dde70486a1 apply user config changes in sandbox mode 2022-12-20 23:07:43 +11:00
Jesse Duffield
e3c6738535 remove snapshot approach for new integration tests 2022-12-20 22:45:03 +11:00
Jesse Duffield
52316e628e fix broken CI (see https://vielmetti.typepad.com/logbook/2022/10/git-security-fixes-lead-to-fatal-transport-file-not-allowed-error-in-ci-systems-cve-2022-39253.html)
try this

WIP
2022-11-12 10:53:12 +11:00
Gustavo Andrioli
39e84e13f4 Use lazycore utils: Clamp and GetLazyRootDirectory 2022-10-15 13:55:44 -03:00
Jesse Duffield
6dca3e1766 allow two attempts on CI 2022-09-16 22:31:46 -07:00
Jesse Duffield
7af7af27c6 various changes to improve integration tests 2022-09-16 08:42:39 -07:00
Ryooooooga
6248091e9c
test: improve integration test portability 2022-08-18 23:48:53 +09:00
Jesse Duffield
5173d7f5e1 better CLI interface 2022-08-14 17:20:52 +10:00
Jesse Duffield
349a7d2453 even better structure 2022-08-14 11:24:07 +10:00