Clojurians Log v2

@seancorfield is this supposed to work in expectations.clojure.test?

(deftest submap-test
  (expect (more {:a 1} {:b 2})
          (in {:a 1 :b 2 :c 3})))

ERROR in (submap-test) (xxx.clj:18)
Uncaught exception, not in assertion.
expected: nil
  actual: java.lang.IllegalArgumentException: more should only be used inside expect

the reason im trying to do it this way, is that i was hoping to get a shorter error message when the test fails and i wouldn't need to rely on some nice diffing extension to clojure.test to pin-point the error

@onetom No, you can't use more/`in` like that.

more is intended to be used with a series of predicates that can be "expected" of the actual value.

You could (expect {:a 1 :b 2} (in (some-expression))) -- that would make sense.

The "foobar" in this example (from the README) totally suggests that I can just use any of the basic "expected" value types:

(expecting "string behavior"
    (expect (more #"foo" "foobar" #(clojure.string/starts-with? % "f"))
            (str "f" "oobar"))

(expect (more e1 e2 ...) actual-expr)

(and (sequential? e) (= 'more (first e)))
      (let [es (mapv (fn [e] `(expect ~e ~a ~msg ~ex? ~e')) (rest e))]
        `(do ~@es))

But in does its transformation first and that's what prevents the above from working.

I've taken a couple of runs at it now and I can't get all cases to work with any of the rewrites I've done so far.

Okay, thanks. I will try to internalize how it works 🙂 I'm just asking these questions because I will have to teach this to my colleagues eventually and I want to be ready if they ask me why is it like this.

Classic Expectations doesn't support that usage either, BTW:

failure in (NO_SOURCE_PATH:1) : user
(expect (more {:a 1} {:b 2}) (in {:a 1, :b 2, :c 3}))

           Using both 'in with a map and 'more is not supported.

To be honest, the reason I was thinking about splitting up the map testing is because Cursive doesn't show me a proper diff when I use expect. If I just use (is (= {expected map,,,} {actual map,,,})) , then I can get a nice diff, but that doesn't allow extra keys in the actual map... 😕

That's a nice error message though; would worth porting it over!

Yeah, I've done quite a bit of work on (new) Expectations to make it work with Cursive as best I can, but there are several corner cases that are a bit harder to make work properly (and I don't use Cursive so it's mostly been guided by Colin himself on that).

I've actually tried to use kaocha's REPL support with cursive and it's not bad, just not very integrated with Cursive...

Have you tried using Paul Stadig's Humane Test Output? That helps a lot in some cases (Expectations has built-in support for it -- you just need to add it to your classpath and Expectations enables it automatically).

sure, but it's not compatible with Cursive

Ah, because Cursive messes with the clojure.test reporting machinery I suspect?

Cursive even prints an error message that it has detected the presence of humane output

yes, it does, so it can put gutter icons next to failing tests and can underline the failing case, which i find really helpful

Leiningen also tries to "help" by injecting its own stuff into clojure.test's reporting machinery. It's very hard to do any sort of custom reporting and still work with both Cursive and Leinningen.

But my plan B is to learn CIDER slowly 🙂 I'm avoiding Leiningen. Too much extra complexity and I'm also very impatient when it comes to REPL startup time. Plus it's harder to teach, when I have to admit eventually that there is a new, official, leaner way to do most of what lein does...

One of the things I like about Atom/Chlorine is the minimal overhead of tooling. No nREPL, no messing with clojure.test reporting. Just a straight up Socket REPL in any Clojure process and you're off to the races. It even does auto-complete without needing dependencies in your code.

I use the execution interruption feature quite a lot though and that doesn't work with a socket REPL.

I also used some unicode function names, like • or ∆, which is also not supported over socket REPL

But because of your tweets, blog articles and slack messages, I did look into Atom and Chlorine, so thanks a lot for those efforts!

I'm quite open to any tooling, but I'm trying to build a team and the current ppl are quite insistent on vim or spacemacs, which made me even try ideavim + intellimacs with intellij 🙂

Are you using some solution to avoid accidentally printing too long data?

Chlorine does some stuff with unrepl under the hood to deal with that. And provide execution interruption. I don't find I run into either of those issues in my day-to-day work anyway.