charmbracelet / charmbracelet/x
teatest: Obtaining final state of terminal
- Dominant language
- Go
- Stars
- 314
- Forks
- 94
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 2
Description
I'm not sure if I'm looking at this the right way. Here's what I'm trying to achieve:
Say I have a program that starts by making some asynchronous request to an external system (with a `tea.Cmd`).
In my tests I use a fake instead of the real system. My fake returns a result with a delay of a few milliseconds.
Now I want to test that, when the command is complete, my program displays "foo" and it doesn't display "bar". Testing that it displays "foo" is easy with `WaitFor`.
```
teatest.WaitFor(
t, tm.Output(),
func(bts []byte) bool {
return bytes.Contains(bts, []byte("foo"))
}
...
)
```
But how do I test that the program doesn't display "bar"?
One approach would be to wait until the program displays "foo", and then get the `FinalOutput` and assert that it doesn't contain "bar". This approach has two issues:
1. With the current implementation, as soon as I've used `WaitFor` I've consumed part of the output, so `FinalOutput` will not actually give me the final "display".
2. Even if I could use `WaitFor` without consuming the output, the condition "contains 'foo'" still doesn't give me any guarantee that I'm looking at the final state. The program could be in the middle of writing out the output.
Before switching to teatest, I was using a homemade solution for testing where I didn't have problem 1 above but I still had problem 2. Essentially I haven't found a way to wait until the program has reached a "stable" state, for lack of a better term. I suppose that would be a state where there are no commands still pending to return a result, and the program has completely processed all the pending messages.
Am I missing something?
Contributor guide
Research direction
Start by reading teatest.WaitFor, tm.Output(), and FinalOutput to understand how output is consumed and when terminal state is observed. Reproduce the delayed fake-command scenario, then define a way to identify the final stable state so tests can assert that "foo" is present and "bar" is absent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100