-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[STACKED] [WIP] [UX feedback requested]: testing logs user experience #4080
Open
apostasie
wants to merge
18
commits into
containerd:main
Choose a base branch
from
apostasie:tigron-4-require
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: apostasie <[email protected]>
Signed-off-by: apostasie <[email protected]>
Signed-off-by: apostasie <[email protected]>
- use internal/com instead of icmd - move pty from test/internal to internal - update go mod, sum, and depguard Signed-off-by: apostasie <[email protected]>
Signed-off-by: apostasie <[email protected]>
- Background() signature change - command creation change Signed-off-by: apostasie <[email protected]>
- Background - Feed, WithFeeder, WithPseudoTTY - use exit code consts where appropriate - some --quiet Signed-off-by: apostasie <[email protected]>
This commit relaxes line length from 100 to 120, and disables a bunch of linters we do not want. Signed-off-by: apostasie <[email protected]>
Mimicry is a lightweight, zero dependency mock mechanism created to ease testing of Tigron. Since Tigron heavily relies on *testing.T, it is currently hard to test. Moving away to a tig.T interface instead of *testing.T will unlock the ability to mock. Mimicry does provide: - recording of all function calls, with arguments and complete stack trace (see Report()) - optional custom handling of function calls (see Register()) - QOL: fancyfied OCS8 links allow opening files from traces in terminal UX is largely in flux right now and experimental, but the objective is to: - do not require code generation - do not abuse reflection - keep the amount of boilerplate to the absolute minimum for the mock consumer - ... and as small as possible for the mock creator - keep zero dependencies This commit also introduce the tig.T interface to be used everywhere inside Tigron in the future, along with a complete mock for it. Mimicry is not meant to be used directly for now, though, if there is interest, a future version might graduate out of `internal`. Signed-off-by: apostasie <[email protected]>
This brings a set of enhancements to assertive: - function name simplifications - generics-ifying of some functions that can be used on comparables - additional methods (Match, DoesNotMatch) - debugging output is made clear, along with OCS8 link and excerpt of the test file - all methods can now elect to Fail later instead of FailNow - Check method is removed (^ because of above) - all methods can now elect to silence output on success Other Tigron files are updated to adopt these changes: - method names update - comparators move away from Check and now fully leverages assertive This also adds a large number of tests for assertive, leveraging mimicry. Signed-off-by: apostasie <[email protected]>
Prior, only BlackList-ing of environment variables was supported, and solely for exact variable names match, or "*" for all. This changeset introduces: - WhiteList-ing - prefix matching for env var names (eg: "THING_*" can now be used to white/black list any env variable which name starts with THING_) Signed-off-by: apostasie <[email protected]>
This is mostly a cosmetic changeset: - refined golangcilint, explicitly calling which linters we really care about, along with settings for revive - comments on reasons for some of //nolint - comments line breaks - additional FIXME information - assert type check fixes - const-ification - overall making linter happy(-ier) - some tests enhanced with added info And: - adding a WhiteList test for internal/com Signed-off-by: apostasie <[email protected]>
This changeset adds expect.JSON[T any], which will allow easier testing of json output and hopefully remove a lot of boilerplate unmarshalling / assert in tests. It also adds an extensive doc.md document about comparators (plan is trim down the main documentation to a small set of simple examples, then link to these "advanced" docs for further reading), which will allow for easier documentation maintenance and more approachable reading. Signed-off-by: apostasie <[email protected]>
Signed-off-by: apostasie <[email protected]>
In some cases, exec is just really slow. Adjusting tests so that we start counting after the command actually started. Signed-off-by: apostasie <[email protected]>
Turns out exec could be really slow in certain circumstances, and we should only measure time once the command is done starting. Signed-off-by: apostasie <[email protected]>
Signed-off-by: apostasie <[email protected]>
Here is the text version of that same failure, copy-pasted from my terminal.
|
Following on assertive debugging info cleanup, this revamp how we display failures. - previously, every assert failure would receive the entire execution information - we no longer do that and instead print out command information first, separately - a lot of headers were printed about different stages (setup, cleanup), even when there was nothing done in these stages, resulting in a lot of noise - the new display embraces a more structured, tabled output, that should significantly enhance legibility Signed-off-by: apostasie <[email protected]>
0ed97c0
to
a3d981b
Compare
1 task
27 tasks
Thanks, the output looks better now |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
<!> Blocked by <!>:
This PR focuses specifically on enhancing the human experience of looking at this:
I do spend a lot of time debugging on the CI, or locally, and here are my issues with this:
It is all packed, and very hard to distinguish one line from the other - everything visually stands at the same level - headers, context information, failure, file and line numbers.
This here is actually a simple failure - for more complex ones, it literally takes minutes of squinting to figure out where is the command that was run, and more time to figure out what is the "failure".
More often than not, the failure is really cryptic, as in
false is not true
.Yeah, no shit Sherlock.
So, you do have to context switch to an IDE, find the file, go to that line number, try to understand the test, read the tea leaves, etc.
Also, since the filename is shown as basename only, I regularly open the wrong (identically named) one.
Context is hard to figure out too.
There are empty sections ("Setup") - did anything run in there? or not? if nothing ran, why show the section?
If something ran, what was it so that I can reproduce the context before trying to debug the command.
Env
is a can of worms on its own - useful, but also very loud.This PR would like to propose we address all these issues:
actual
, what wasexpected
, what did it all mean?I do appreciate that everyone has their own tastes and preferences when it comes to visual things, so, I do not expect that we are going to agree on every detail, and we will have to settle on something.
The important part here is to come up with something that objectively addresses these issues - then we can bikeshed all we want on pink vs. green :-) (or I will make the output configurable so that different projects can pick their poison).
I truly believe very few people engage with the CI failures not because they are lazy, but because it looks like a train accident.
PLEASE NOTE THAT THIS PR CODE IS NOT READY FOR REVIEW.
What is ready for review and discussion right now is the visual end-result (see next comment).