Interesting idea. Definitely something I hadn't thought of before. I haven't had a chance to play around with it or think about it too much yet (just got back from a vacation) but definitely will over the next couple of days.

To summarize, the basic idea is to expose an option that starts a repl and runs tests automatically. Having a repl exposed is useful for changing state that isn't blown away by refreshes (such as modifying timbre's logging levels?).

Is that summary correct?

Sounds right, often I'll want to change the log level to debug (from warn) after seeing a failure and re run the tests.

Great.

Having thought about it a bit and conferred with a couple other people on it and I'm cool with proceeding with this feature. Its interesting and something I never even considered.

Could you update README to add some text to the feature list near the top and a more detailed section later with a description of the feature and motivation and put something in CHANGES.md (add a NEXT section at top with a sentence).

If there is anything else you feel needs to be added feel free to do it.

Thanks for the PR and putting in the work.

Ok I think it's all good to go, let me know if you want anything else added/changed.

I'm thinking as a later endeavor I may try to integrate tab-completion and history (arrow navigation), maybe using trptcolin/reply.
For now using rlwrap lein test-refresh :with-repl should suffice for most uses cases of this anyway.

Woops didn't mean to close it....

Thanks for the submission. Merged. Will deploy shortly.

Version [com.jakemccrary/lein-test-refresh 0.14.0] released with this feature.

Enjoy.

Really like this!

Is it possible to expose an nrepl port? This way my editor could easily jack in.

@donbonifacio Probably requires pulling in another dependency to get nrepl working. If you think it would be useful feel free to give it a shot and then try it out for a while.

I'm not sure I'd want a repl that automatically refreshes namespaces as you'll end up losing state (not that having lots of state around in a repl is great anyway) whenever a namespace refreshes.

If you do it and find it useful I'd be willing to accept a PR. I'm also not sure how this changes with socket repl changes in 1.8 (if tooling eventually moves to use that instead of nrepl, I'm less up-to-date with various toolings thoughts on that).

In our scenario we don't have state on the tests, and we rely on the reply when we want to run just a specific test/code. So this would work fine for me. I'll try to investigate what's needed to jack in. :)