Improvement areas

[olimorris]

This adapter has been stable for a while now and I'm keen to understand areas where it could be improved.

Are there any areas of the API that are frustrating? Any RSpec tests that aren't detected? A better way to format output?

[olimorris]

@mmirus - anything you've noticed since using it?

[mmirus]

👋 Unfortunately, I've barely used it--pretty much only to figure out the docker thing. So far, the only negative thing I've noticed is that the summary panel reports more tests failed than actually did. Edit: The failures also show up in the main UI if I open those tests; it's not just the summary.

In the image below, you can see in the panel that only one test failed (the one I set up to deliberately fail in the current buffer). But in the summary panel you can see failure indicators in a few other spots in the tree. I'm not sure if that's related to the docker stuff, or would be happening regardless.

It could also totally be something odd with our test suite (characters in test names/descriptions, etc.).

I'm not doing a lot of ruby dev ATM, but will provide more feedback here or open tickets if I see anything else!

[olimorris]

I hope you're loving using Ruby. I don't get to play with it anymore (since I had to can my startup) but using Rails everyday was an absolute joy

[mmirus]

I like Ruby (and Rails), but I never end up working with them for long enough at a time to get and stay fully comfortable. TBH, the main thing I miss when working with Ruby is a top-tier language server. It's hard to beat having tsserver or even Intelephense helping you out, and I've never gotten something working that well for Ruby. Sorry to hear about your startup!

[olimorris]

Completely agree on the LSP front. Tbh I found Ruby tooling generally to be a level or two below that of JS and even PHP. When I had some spare time I was trying to contribute to the Ruby Neovim community as much as possible. I added Ruby support to Refactoring.nvim (that whole plugin seems broken now unfortunately) and created this RSpec adapter mainly to scratch my own itch but also because I feel it's such a beautiful language that a decision not to use it could be made because of the tooling situation; and that sucks.

If ever you come to use Treesitter and Ruby, there is now a body_statement you can query. Before, trying to select anything within a method or class was an absolute mission. But Max approved a kick-ass PR. Unfortunately the Playground website isn't reflecting the new parser.

Oh and worth checking out Ruby Debug btw...it's an absolutely brilliant debugger.

[davidmh]

Hi @olimorris, great work with this adapter, I've been enjoying it for a few days.

From what I gathered in #17, the dap strategy is not available yet.

So I was wondering if there's a way to automatically attach only when the pry REPL kicks in.

I'm guessing the answer is no since that sounds like something that should be handled at the neotest level, not the strategy, but maybe you can think of something?

[olimorris]

Hey @davidmh. I never actually got around to exploring how to using Neotest and debugging. Partly that's because I accomplished everything I needed with nvim-dap and Ruby Debug (a link to my setup here). I would be interested in picking it up at some point. Main priority at the minute is creating a robust way of testing this adapter

[davidmh]

That makes sense, I'll just go with nvim-dap. Thanks!