tendersearls / tldr

A Ruby test framework for people who don't have time for slow tests 💣💥
MIT License
250 stars 4 forks source link

Thoughts on how to solve for debugging tests? #2

Closed thewatts closed 1 year ago

thewatts commented 1 year ago

Hi there! :wave:

I watched your pairing episode and started a sample project to poke around with TLDR. Really cool project!

Maybe this is just me - but I tend to do a lot of introspection to poke around in an object, test, etc - and pry is my debugger of choice.

To my initial surprise, throwing a binding.pry in my test - while it halted execution, the time bomb exploded shortly after. Upon digging into the code - this makes sense.

Wondering - would it be helpful to have a debugging flag? (similar to ENV["CI"])?

CleanShot 2023-10-04 at 15 43 59@2x
coreyhaines commented 1 year ago

There is a check for an IRB context, but I wonder if it doesn't detect whatever is needed for pry. Is there another context to check you can look into?

https://github.com/tendersearls/tldr/blob/main/lib/tldr/runner.rb#L28-L34

I wonder if you could check for something around Pry.current. https://github.com/tendersearls/tldr/blob/main/lib/tldr/runner.rb#L28-L34

coreyhaines commented 1 year ago

Spent some time looking through the pry source to see if there was a straight-forward way (like it does with IRB) to detect if a pry session is happening, but wasn't successful. Hopefully someone else will have better luck finding the right check.

coreyhaines commented 1 year ago

LOL! I'm not saying to do this, but probably could use Thread.list in time_bomb and use Thread#thread_variable_get to check for the :pry_critical_section value > 0.

Something awful like

pry_running = Thread.list.any? { _1.thread_variable_get(:pry_critical_section).to_i > 0 }

Again, super LOL!

searls commented 1 year ago

Yes, we look out for IRB sessions but not for Pry, because AFAICT in binding.irb has become sophisticated enough to more or less obviate Pry.

I'm genuinely curious about what folks who are still using Pry with intention (as opposed to force of habit) in Ruby versions ~3.1 and later are getting out of it that IRB can't do. I've dropped Pry use entirely as a result, as well as that in recent years Pry maintenance has slowed way down and has resulted in more than a few bugs

thewatts commented 1 year ago

Honestly, (and maybe this is just me) - but for whatever reason the color schemes I use and the autocomplete with IRB just do not mix (note: I'm partially colorblind).

It's what has kept me going back to pry.

I've tried both Darkula, and Catppuccin (current)

image

I've tried to figure out a way to fix this - but haven't had any luck thus far (~and haven't yet added an issue in the project~)

Update: I've submitted an issue with a question regarding how to fix this on the IRB project directly.

searls commented 1 year ago

@thewatts thanks for submitting the issue to the IRB project. Glad to see they seem to be on it

st0012 commented 1 year ago

Copying my response from the IRB issue for exposure:

We’re aware of the problem and have started a discussion on introducing related APIs for customization in Reline (the gem that powers autocomplete dialog): https://github.com/ruby/reline/pull/552

As a short-term solution, you can disable IRB's completion feature with:

  1. Setting IRB_USE_AUTOCOMPLETE=false environment variable
  2. Setting IRB.conf[:USE_AUTOCOMPLETE] = false in your PROJECT/.irbrc or ~/.irbrc