Replies: 1 comment 3 replies
-
This actually sounds like a fairly reasonable approach that would work for many test scenarios.
You're making good points and I think I agree: we should export
There isn't and to be frank we're currently experimenting with ways of testing components and even entire tea apps ourselves. Any insight is greatly appreciated and will help shape what this looks like.
Yes, that's the plan!
👍 I came to the same conclusion the other day. CCing @caarlos0 for his opinion on the matter. |
Beta Was this translation helpful? Give feedback.
-
|
regarding testing, I started experimenting a few days ago a "teatest" framework, see https://github.com/charmbracelet/bubbletea/compare/test?expand=1 the idea behind it was basically to assert the output against golden files. I'm not sure how well it'll work against complex bubbles though... just kinda threw some code in a file so I didn't forget about it. Feel free to try/give feedback though. |
Beta Was this translation helpful? Give feedback.
-
|
(sorry in advance for the verbosity...) @muesli thanks for the info and context! I'll keep a watch on #114 (I have an evil/temporary hack in place for now -- @caarlos0 👋 congrats on the new gig! re: testing...
I'm doing the same approach. Generally I try not to use snapshot testing, however, in my opinion it's really well fit for frontend component testing (and since bubbles are basically that.... peanut butter + jelly). I like the choices made for interact func(p Sender, in io.Writer),
assert func(out io.Reader),Why I like this:
Nits:
I think your approach probably side steps most of the issues I was having (I'll give it a good shot later this week). To be transparent about what I tried out before checking back here.... I tried out a what I thought would be a minimal approach, but ended up being somewhat hokey: (sorry for the code dump here, working in a private repo right now) func RunModel(t testing.TB, m tea.Model, iterations int, message tea.Msg) string {
if iterations == 0 {
iterations = 1
}
m.Init()
var cmd tea.Cmd = func() tea.Msg {
return message
}
for i := 0; cmd != nil && i < iterations; i++ {
msgs := flatten(cmd())
var nextCmds []tea.Cmd
var next tea.Cmd
for _, msg := range msgs {
m, next = m.Update(msg)
nextCmds = append(nextCmds, next)
}
cmd = tea.Batch(nextCmds...)
}
return m.View()
}
func flatten(p tea.Msg) (msgs []tea.Msg) {
if reflect.TypeOf(p).Name() == "batchMsg" {
partials := extractBatchMessages(p)
for _, m := range partials {
msgs = append(msgs, flatten(m)...)
}
} else {
msgs = []tea.Msg{p}
}
return msgs
}
// to get around batchMsg not being exported... not really needed in the long run hopefully
func extractBatchMessages(m tea.Msg) (ret []tea.Msg) {
sliceMsgType := reflect.SliceOf(reflect.TypeOf(tea.Cmd(nil)))
value := reflect.ValueOf(m) // note: this is technically unaddressable
// make our own instance that is addressable
valueCopy := reflect.New(value.Type()).Elem()
valueCopy.Set(value)
cmds := reflect.NewAt(sliceMsgType, unsafe.Pointer(valueCopy.UnsafeAddr())).Elem()
for i := 0; i < cmds.Len(); i++ {
item := cmds.Index(i)
r := item.Call(nil)
ret = append(ret, r[0].Interface().(tea.Msg))
}
return ret
}With testing like: func subject() (*progress.Manual, *progress.Stage, Model) {
// snip...
}
func TestModel_View(t *testing.T) {
tests := []struct {
name string
bubbleGen func(testing.TB) Model
iterations int
}{
{
name: "in progress without progress bar",
bubbleGen: func(tb testing.TB) Model {
prog, _, model := subject(t)
prog.N, prog.Total = 40, -1
return model
},
},
{
name: "in progress with progress bar",
bubbleGen: func(tb testing.TB) Model {
prog, _, model := subject(t)
prog.N, prog.Total = 40, 100
return model
},
},
{
name: "successfully finished hides progress bar",
bubbleGen: func(tb testing.TB) Model {
prog, stage, model := subject(t)
// note: we set progress to have a total size to ensure it is hidden
prog.N, prog.Total = 100, 100
stage.Current = "done!"
return model
},
},
{
name: "successfully finished keeps progress bar shown",
bubbleGen: func(tb testing.TB) Model {
prog, stage, model := subject(t)
tsk.HideProgressOnSuccess = false
// note: we set progress to have a total size to ensure it is hidden
prog.N, prog.Total = 100, 100
stage.Current = "done!"
return model
},
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
var m tea.Model = tt.bubbleGen(t)
tsk, ok := m.(Model)
require.True(t, ok)
got := testutil.RunModel(t, tsk, tt.iterations, TickMsg{
Time: time.Now(),
sequence: tsk.sequence,
ID: tsk.id,
})
t.Log(got)
snaps.MatchSnapshot(t, got)
})
}
}What I don't like about my approach:
At a high level the "zoomed in" testing approach works, but future iterations shouldn't try to recreate the cmd-msg-update-view loop outside of bubbletea... that will lead to problems in the long run. This goes back to being able to leverage that functionality from bubbletea by factoring out the important bits. What I do like about this approach:
I realize I listed this as essentially a "pro" for your testing approach, so it shows that I haven't made up my mind here! I get a feeling with the right testing options for a tea application the full-tea-program is the way to go (or at least should be one of the easy-to-reach-for testing utilities). Something like: tea.NewProgram(tea.WithoutSignals())or tea.NewProgram(tea.WithTestConfiguration())Happy for thoughts! |
Beta Was this translation helpful? Give feedback.
-
|
ah, cool! I changed the names around a bit, and the assertion now get a Also opened a PR: charmbracelet/bubbletea#352 |
Beta Was this translation helpful? Give feedback.
-
I feel like I could be missing something, but I'm having a hard time testing individual bubbles/components. I want to keep testing as simple as possible, so I felt the best way would be to instantiate the component model, send an initializing message to
Update()and callUpdate()in a loop feeding any messages back intoUpdate()until no commands are returned. I realize this isn't perfect, there are some edge cases with this, however, it has the nice property of being able to treat the component like a black box, send a sequence of messages to the component, and the assert the string output fromView().The problem I'm running into is that
tea.Batch()returnsbatchMsg, an unexported type. Though it represents[]tea.Msg(something that is exported) I still can't type assert to the transitive representation, thus, I can't really test in the way I described.Testing with an entire
tea.Programseems really heavy and would bring in a lot of complexities that I would like to avoid.I could craft all of the expected messages from sub components myself (this would be the closest testing approach to what I originally described), however, this level of mocking seems heavier than I'd like. For instance, If I have a component that uses other components (say a component that uses the progress-bar and spinner bubbles), I don't want to mock out the other component
Update()calls (by ignoring the results and crafting my own messages, which means I need to craft progress-bar frame messages, spinner tick messages, etc) --I'd prefer to see what the effect on theView()output from a small set of initializing messages and "see" how the system of components settles out... I don't see how to do this (in a straight forward way)....with the context explained, here's a few questions:
batchMsgreally need to be unexported? Is this really an internal concern to bubble tea? (if it was exported it would help me out a lot)programconcerns, such as signal handling, etc).Beta Was this translation helpful? Give feedback.
All reactions