Slightly different approach, but appears to have the same overarching goals: https://github.com/bullet-train-co/magic_test

„Magic Test allows you to write Rails system tests interactively through a combination of trial-and-error in a debugger session and also just simple clicking around in the application being tested, all without the slowness of constantly restarting the testing environment.“

I will keep an eye on both now, probably they will compliment each other at some point in time.

Very cool! Will definitely check it out.

Random question: when you "pause" a test, is it actually pausing the capybara/rspec test such that I can have a breakpoint/debugger/REPL experience to try out various capybara/rspec code?

The reason I ask: one of the slowest/annoying parts of writing capybara tests is the context jump between "this is the css selector i get from chrome dev tools" and "this is the capybara/rspec code which I use in my tests". While they are similar, there are differences which slow things down: locating buttons based on text (vs css), case sensitivity issues with text, ambigious matches, wanting to use nested "find" calls [ie: find(css: ".modal").click_button("Close")], trying to use page objects vs selectors directly in tests, etc.

Often times my first attempt is "close" but not quite right, which compounds when you hit that on most steps of the user's flow.

super stretch goal: if you are using page objects in your rails app, if the page objects where written in a way that "cyperful" could parse them, you COULD have a feature where cyperful could highlight the page objects on the page. So instead of showing me css selectors, you draw a box around a page/section object.

I know that Playwright was doing some cool stuff with their "Pick Locators" and it allowing you to test playwright locators in the tool, not sure if this ever got extended to Page Objects or not. https://playwright.dev/docs/test-ui-mode#pick-locator

I write system tests like this with the REPL often. I just change the Capybara driver from its usual headless_chrome to chrome and put a debugger (or pry) breakpoint in the RSpec example. From there I just "drive" from the REPL, testing my finders/matchers and building up the test example as I go. As you suggest, being able to use dev tools directly in the browser being driven by Capybara is massively helpful during this stage.

at one point i started to make a gem called "dora" where you could "explore" the page with methods around the capybara driver, but never finished it. for example: page.find_blog_posts.highlight_all would draw a blue box around each "blog_post" element.

> is it actually pausing the capybara/rspec test such that I can have a breakpoint/debugger/REPL experience to try out various capybara/rspec code

That's a good idea. The actual method of pausing is with a ruby Queue#pop within the same thread that the actual ruby test source code is running in. I'm not sure the exact mechanism, but I assume you could run a binding.pry instead, as long as you can "cancel" it from another thread.

Side question: What tool are they using to get "resolution independent" zoom on the video?

I noticed the UI stayed crisp on zoom and had me wondering. (I don't do video work so maybe it's common in AE)

This could be a nice UI to let you create the test visually.

I like this idea, it's even on my future roadmap: "Record browser interactions to save as ruby code"

Is there an example of a tool doing this well?

I watched the demo for a comment made above, and it looks like the gem can do what you're talking about:

> Slightly different approach, but appears to have the same overarching goals: https://github.com/bullet-train-co/magic_test

If this avoids save_and_open_screenshot loops, it will be very valuable for reducing debug grind. Will take a look.

wow, this is awesome, thanks for sharing!

looking forward to trying this!