This seems like it might not be fixable. I'm not sure, the case isn't clear enough to me, in some cases it jumps back to deftest without the testing, I think this is actually related to assert-expr rather than a true failing test.

I've run into an "issue" with *out* during tests. Is anyone able to confirm what I've tried to puzzle out about emacs here: https://github.com/SevereOverfl0w/vim-replant/issues/9 ? I tried looking for an open issue for this, and failed, which makes me think I'm missing something, surely the *out* is really important!

Some example to play with will help to narrow things down, as I’m not quite certain what exactly are you doing/trying to do.

I'm thinking about the case where a test does something like (is (= 1 (do (println "calculcating 2") 2))). Currently that output is lost?

From an nrepl level, it shows up before the test results do, so it's contextually lost. Compared with what happens when running clojure.test normally, this is a little different.

@mathpunk This evaluation is not really done by CIDER - it’s just a basic nREPL op. There shouldn’t be a difference in the evaluation and I’ve got no idea why you experience this problem.

@dominicm As you assumed - the output currently ends up in the REPL buffer. It was either this or popping some output buffer for each test run, and this seemed like an adequate solution for the time being.

@bozhidar Interesting. I suppose solving this would be solved by making tests real-time also? https://github.com/clojure-emacs/cider/issues/696 as mentioned here.

Yeah, it would.

I expected more people would be interested in this and someone would have solved it by now, but it turned out I was wrong. I know that if I was doing Clojure every day I’d certainly have fixed this myself. 🙂 For a big test suite the current behavior can be quite annoying.

In vim it is worse, the whole UI is locked up while tests run. Having this run real-time would be massively beneficial to me there.

I can imagine. I assume it won’t be hard to switch the evaluation of the tests to be reported individually and to just keep the same format for the final report data in the end. Something like this would also allow clients to show some progress indicators.

I'll have a look into this on my next burst of work.

:thumbsup:

Can anyone take a guess why the require option on the ns macro wouldn't be able to detect something on the class path that the require function could find?

Asking here because I'm so confused that I'm worried this might have something Todo with cider and nrepl. I'm using deps + boot tools deps, then starting a repl via boot deps repl and connecting to it with cider

Does it work at a repl without cider involved? Seems like an easy test to try

But straightforward code evaluation isn't much affected by CIDER

The require function works at the repl didn't try the ns macro.