You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I find it challenging to test individual child models in TUIs built using a tree of models, as described in this blog post. This issue arises because the teatestTestModel does not provide a way to access or interact with the underlying tea.Model before the tea.Program is "finished" (usually triggered by returning tea.QuitCmd from the model).
The current API supports inspecting string output mid-run via TestModel.Output, but this is insufficient when testing models that communicate state changes via custom tea.Msgs. This limitation forces testing of individual models through their parent/root models or requires forking teatest to expose this functionality.
Describe the solution you'd like
A TestModel.WaitForMsg function that blocks until a specific tea.Msg is received. This would enable testing of tea.Msg-driven state transitions in models without relying solely on string output. The existing TestModel.WaitFor function, which blocks for specific output, should also be renamed to WaitForOutput for clarity.
This change would facilitate a more robust approach to testing TUIs by allowing:
End-to-end tests: Using WaitForOutput to verify user-facing outputs.
Integration tests: Using WaitForMsg to assert program state transitions and verify key tea.Msg emissions.
Describe alternatives you've considered
Forking the teatest package to expose the inner tea.Model during execution, but this approach is complex since tea.Program does not natively support accessing the model mid-run.
Testing models through their root model, which introduces unnecessary complexity and reduces test isolation.
Ultimately, I shifted focus towards blackbox testing (WaitForOutput) and integration tests (WaitForMsg). This approach aligns with TUI testing being closer to integration testing than unit testing.
Additional context
This feature request stems from testing a TUI structured with nested models in my open-source projects, such as Tetrigo (see this PR). In these cases, child models emit custom tea.Msgs to signal state changes (e.g., transitioning from a menu to the game screen).
I have a working branch implementing WaitForMsg in teatest and an example in my project. I will create a PR to link my current code to this issue, but expect further discussions to take place before making changes to the API.
In addition to the mentioned changes, I have also proposed a rename of the existing function WaitFor to WaitForOutput in the hope that it will not get confused with the new method.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I find it challenging to test individual child models in TUIs built using a tree of models, as described in this blog post. This issue arises because the
teatest
TestModel
does not provide a way to access or interact with the underlyingtea.Model
before thetea.Program
is "finished" (usually triggered by returningtea.QuitCmd
from the model).The current API supports inspecting string output mid-run via
TestModel.Output
, but this is insufficient when testing models that communicate state changes via customtea.Msg
s. This limitation forces testing of individual models through their parent/root models or requires forkingteatest
to expose this functionality.Describe the solution you'd like
A
TestModel.WaitForMsg
function that blocks until a specifictea.Msg
is received. This would enable testing oftea.Msg
-driven state transitions in models without relying solely on string output. The existingTestModel.WaitFor
function, which blocks for specific output, should also be renamed toWaitForOutput
for clarity.This change would facilitate a more robust approach to testing TUIs by allowing:
WaitForOutput
to verify user-facing outputs.WaitForMsg
to assert program state transitions and verify keytea.Msg
emissions.Describe alternatives you've considered
teatest
package to expose the innertea.Model
during execution, but this approach is complex sincetea.Program
does not natively support accessing the model mid-run.Ultimately, I shifted focus towards blackbox testing (
WaitForOutput
) and integration tests (WaitForMsg
). This approach aligns with TUI testing being closer to integration testing than unit testing.Additional context
This feature request stems from testing a TUI structured with nested models in my open-source projects, such as Tetrigo (see this PR). In these cases, child models emit custom
tea.Msg
s to signal state changes (e.g., transitioning from a menu to the game screen).I have a working branch implementing
WaitForMsg
inteatest
and an example in my project. I will create a PR to link my current code to this issue, but expect further discussions to take place before making changes to the API.In addition to the mentioned changes, I have also proposed a rename of the existing function
WaitFor
toWaitForOutput
in the hope that it will not get confused with the new method.The text was updated successfully, but these errors were encountered: