Hello, fellow Clojurians. One problem I've run into when stubbing fns is that with-redefs doesn't play well with concurrency. E.g. http://clojuredocs.org/clojure_core/clojure.core/with-redefs#example_994 The problem arises because, quoting with-redef's docstring, "These temporary changes will be visible in all threads."
Let's say you're stubbing the fn 'f' with the fn 'stub'. Here is an irritating sequence of events: 1: test1 redefs f to stub, saving the initial fn 2: test2 redefs f to stub, saving **the current value of f, which is stub** 3: test1 completes, resetting f to its initial fn 4: test2 completes, **resetting f to the stub fn** 5: test3 starts, expecting the fn f to work normally, and fails We actually ran into the problem because there was a delay in our app's init fn, and so the first one of our integration tests that ran permanently rewrote some fns. I would imagine that this could even happen in unit tests, though, if your test runner executed tests in parallel. Has anyone run into a similar problem, and come up with a safer way of stubbing / mocking non-dynamic vars? Thanks, Leif -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
