charmbracelet / charmbracelet/x

teatest: Obtaining final state of terminal

Open
#212 6 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.