James Reeves

No, not currently. However the original author of fixtures [now thinks there are better alternatives](https://stuartsierra.com/2016/05/19/fixtures-as-caches) to them.

> It is not clear how the `:multithread?` option interacts with `^:eftest/synchronized`. A test or namespace that is synchronized will never be run concurrently with another test.

Have you set the `:multithread?` option to `false`?

I've looked through the code, and the vars and namespaces are tested in the order they're found. If we want a deterministic ordering, we probably want to perform a sort...

There shouldn't be; `*test-out*` should be solely reserved for the test reporters. There may be functions that write to `*out*`, but that shouldn't affect `*test-out*` if it's rebound to a...

I like the idea of adding an option, perhaps `:output-file`, that would wrap the reporter in `report-to-file`.

I've tried reproducing this with the following test namespace: ```clojure (ns foo.core-test (:require [clojure.test :refer :all] [foo.core :refer :all])) (deftest a-test (is (= {:a 0, :b 1} {:b 1, :c...

This looks like an issue caused by Ultra, which changes the reporting format for equality assertions. Ideally Ultra shouldn't change the reporting format used by clojure.test, otherwise third-party test reporters...

How is test.check printing these things? A cursory look at the source code suggests its doing so [via the test reporter](https://github.com/clojure/test.check/blob/master/src/main/clojure/clojure/test/check/clojure_test.cljc#L28), so couldn't we add methods for the extra events...

In theory we could extend the current Eftest reporter multimethods with support for the extra test.check events. For the junit reporter, presumably we just want to ignore them.