Fork me on GitHub

OK. I've spent this day debugging a problem where my integration tests just hang indefinitely. Now I've come to conclusion that it is actually a bug in Cursive and more specifically in the part of code that evaluates test assertion diffs. The reason why I've come to this conclusion is because if I execute tests from command line with lein test everything works fine. They also work fine in REPL if I use run-tests. This is true both for command line lein repl and within Cursive lein repl. However, if I use "Run tests in Current NS in REPL" keyboard shortcut (which I use all the time) they hang when a database query is done. To make matters more weird, this doesn't happen with all my tests, just this one causing issues. Also, if I remove assertions using is then they do not hang (but naturally tests are useless). Unfortunately I cannot share code which causes this issue. It is using HikariCP, next.jdbc and PostgreSQL database for this specific test. One additional thing is that my integration tests are wrapped with defintegrationtest macro which I can share:

(defmacro defintegrationtest
  "Defines an integration test. The main effect of this is a proper binding
   to 'lein test :integration'. Otherwise this is identical to normal deftest."
  [name & body]
  (when *load-tests*
    `(def ~(vary-meta
             (vary-meta name assoc :integration true)
             assoc :test `(fn [] ~@body))
       (fn [] (test-var (var ~name))))))


If I change that to deftest the situation doesn't really change though


However I am using test-ns-hook functionality within Clojure test


Sorry for the slow reply on this - is the failing test the only one using test-ns-hook?


I wish I could give more information but this is a super weird bug and it is super annoying

Joe R. Smith14:11:39

Idk if this is a cursive bug, but if I start a REPL from within intellij/cursive and then start a Jetty webserver, the webserver persists after intellij is closed.

Joe R. Smith14:11:12

My expectation is that it'd die with the repl process that started it (nrepl)


@solussd this is what you will get if you try to exit IntelliJ with active REPL session. If you choose "disconnect" then REPL process is left alive and so is your Jetty. If you choose "terminate" REPL process is also killed as is your Jetty. If you however have checked "don't ask me again" and have chosen "disconnect" then it will perform like you described. So no, not a bug in Cursive.


I'm quite certain remembering the option can be reverted from somewhere

Joe R. Smith19:11:00

@niklas.collin thanks- that explains it. I had slightly different reasoning. I assumed, incorrectly, that the repl process was a sub-process of intellij, but that doesn't make sense now that I think about it.


Well it actually is


But it is tracked properly


Happy to help