anomalyco
test(tui): Set up TUI tests
@kommander I have created a comprehensive mock context setup and a few tests to get things going.
My plan was to add tests all day today (Monday). If you are not in a super hurry to maximize coverage, I would like to tinker a bit with the utility functions. Otherwise, we can work on different tests in parallel if you want.
Todos:
- [ ] Reconcile tests marked with test.fail or test.todo, etc
@kommander Please ignore the fact that I sometimes use .ts and sometimes .tsx. I'm having trouble with debugger breakpoints not mapping correctly in .tsx files, so I'm using .ts where possible for now.
If this rings a bell and you know a fix, please let me know. (I'm using vscode)
I am not using a debugger at the moment, so I can't really help with the breakpoint problem, although I suspect the solid plugin compilation messing up the line numbers, the issue exists in tests where in failures the stack traces are wrong. Maybe @Adictya has an idea here.
Regarding the test setup, that is a good start. However I am a bit scared by the many unit mocks. I would rather mock less and at a lower level, so it's more like "integration" tests for the tui, where only the interface to the server/sdk is mocked, so we can control model responses, errors etc. and test how the whole tui actually reacts to it.
That makes sense, though I think a few more context providers should be mocked by default in addition to server/sdk. Please see commit https://github.com/sst/opencode/pull/3789/commits/d86a5cc0da7336aac678a83485c296dd5ab42e8c#diff-4ac50cbf1a587d44e1de3cca0938ee733680bdb151025778d721a6797477d123R19 where I disable some mocks. I tried to choose a reasonable subset, let me know if you disagree.
@kommander Please ignore the fact that I sometimes use
.tsand sometimes.tsx. I'm having trouble with debugger breakpoints not mapping correctly in.tsxfiles, so I'm using.tswhere possible for now.If this rings a bell and you know a fix, please let me know. (I'm using vscode)
I debug directly via bun --inspect-wait=localhost:4000/ot + neovim. For breakpoints I think faced those too I just use the debugger; keyword which works reliably, you can try that maybe
Yeah I also do --inspect-wait. debugger; is better than nothing, but I can't use step functionality cuz the cursor keeps jumping around all over the place.
@kommander Tests are coming along nicely. I expect to have a bunch more ready by end of day. Do you have any special ones to pay attention to?
Btw I also ran into this: https://github.com/sst/opencode/pull/3789/commits/865d6104acb328fdcd3cee3f1dba4b22ab87279c#diff-136aadfe331bad702903358a242e704fbd853464f9e83c6fcd4d54fd3c71258aR353 The workaround is working but thought you might want to know about that error. (without the workaround, sometimes it even segfaults)
Cool, I'll review in a bit. Is that segfault reproducible somehow in a test?
Happens in home.test.ts -> Model dialog -> "should open model dialog". When I skip that test the issue doesn't happen.
At the moment I'm writing the error is always a segfault, but earlier today it would sometimes segfault and sometimes throw EditBuffer is destroyed. Perhaps I refactored something between then and now which changed the behavior.
@kommander I think I found another opentui bug: https://github.com/sst/opencode/pull/3789/commits/b5fa06a175a3bb02e28f554e7a4003a82ee617ee#diff-c63d79e8c8f6134eddfa867a39886598244ee586889c9a52db3ac7160f8b05d9R259 pressTab doesn't respect modifiers
@kommander Can you take a glance at the tests so far and tell me if I am on the right track of what kinds of behaviors should be tested?
@kommander Converted the tests to E2E per dax's suggestion. Found some opentui issues - I'm gonna create gh issues for them after taking a breather. Please give me some feedback (quick glance is fine). I would like to keep writing tests while I'm in the flow, but also don't wanna waste my time diving into a rabbit hole only to have it rejected later.