Modern Java (11+) has jshell, which has interactive goodies like tab completion, documentation display, paren/bracket matching, etc.

it's something.

Step1: Write a test.

Step2, IDE: Right click + Run.

Step2, CLI: $ run <test name>

Bonus: The test is now part of your automated test suite, and will be ran many times to ensure things don't break.

What if you don't know what you want it to do yet? Maybe you have a new API or library you're working with and the documentation is lacking. Maybe you're exploring some dataset trying to figure out what kind of information can be gleaned from it.

Maybe it takes 3 minutes to get it into the state where it failed, so instead of starting over every change you just want to modify the one function over and over.

Doing it in a repl like jupyter has you run the actual code many times as you're writing it so ensure things don't break before you ever save the file. Of course thats not an excuse to skip tests, but if I was going to pick one, I would choose running the code as I write it, instead of testing it after the fact.

A. Then don't submit the exploratory test in your next PR.

B. Then memoize the expensive function to disk. Bonus: Can keep multiple versions on disk, thus can tweak the expensive function while having fast reloads with guaranteed correct version.

Now try to fix the code from the unit test when it breaks and redo the unit test, from the point where it broke.

So that you can run your unit test from some unknown state that may not even be reachable from the current text of the code, rather than running it from the start in a reproducible way? Why would that be something you want?

Unit testing was born in the Smalltalk community, good tooling is orthogonal to having tests.

Throw a breakpoint in the unit test.

It won't work on the CLI version, and unless you are using an IDE with a backtracking debugging it won't help.