test(tui): Set up TUI tests - #3789

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

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: 865d610#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.

Closing this pull request because it has had no updates for more than 60 days. If you plan to continue working on it, feel free to reopen or open a new PR.