test(tui): Set up TUI tests

[veracioux]

@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

[veracioux]

@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)

[kommander]

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.

[veracioux]

That makes sense, though I think a few more context providers should be mocked by default in addition to server/sdk. Please see commit d86a5cc#diff-4ac50cbf1a587d44e1de3cca0938ee733680bdb151025778d721a6797477d123R19 where I disable some mocks. I tried to choose a reasonable subset, let me know if you disagree.

[Adictya]

@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 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

[veracioux]

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.

[veracioux]

@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: 865d610#diff-136aadfe331bad702903358a242e704fbd853464f9e83c6fcd4d54fd3c71258aR353
The workaround is working but thought you might want to know about that error. (without the workaround, sometimes it even segfaults)

[kommander]

Cool, I'll review in a bit. Is that segfault reproducible somehow in a test?

[veracioux]

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.

[veracioux]

@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.