Clojurians Log v2

@camsaul This is not the original Expectations. This is the clojure.test-compatible version. All of the clojure.test tooling works with this version of Expectations.

lein test, Cursive’s test runner, Polylith’s test runner, Cognitect’s test-runner all work with this. And you can mix’n’match “old school” clojure.test assertions and the more expressive expect expressions.

“it looks like the migration path from expectations 1 -> expectations 2 seems like it would be about the same amount of work as migrating directly over to `clojure.test`.” — not sure what gives you that impression? Did you actually check out the docs?

(and, yes, we use this version of Expectations very heavily at World Singles Networks with standard clojure.test runnners)

Right, I understand that. It just seems like the main benefit of upgrading from the class Expectations lib -> Expectations 2 is that is uses clojure.test under the hood, but with the syntax changes it seems you'd have to rewrite everything either way. Example: a classic Expectations test might look like

(expect
 1000
 (inc 999))

(deftest my-test
  (is (= 1000
         (inc 999)))

(defexpect my-test
  (expect 1000
          (inc 999)))

We switched from (classic) Expectations to the clojure.test-compatible version that I developed ages ago. This is the 2.0 version of that library. Migrating to the clojure.test-compatible version was simply a matter of wrapping each namespace’s set of (expect ..) forms in a single (deftest some-name ..) form.

Gotcha. I'm just trying to understand (as the maintainer of a few libraries that still use classic expectations-style tests) if migrating to this Expectations 2 lib would be easier than migrating to clojure.test . And whether this Expectations 2 lib is intended more as a stepping stone to eventually migrating to clojure.test entirely or not

No, you don’t need to migrate to clojure.test. Just wrap (deftest some-name ..) around a big group of (expect ..) forms, and switch from the old Expectations require to this new one. It’s a trivial migration, and can be done one ns at a time.

(that’s how we migrated)

ok, gotcha. that makes sense. thanks

The README link I posted explains why this version exists and what the differences are from the “classic” Expectations. And shows a mix’n’match example:

(deftest mixed
  (is (= 2 (+ 1 1)))
  (expect even? (+ 1 1)))

We’ve been using this version for about two and a half years at work. Happy to help you migrate any of your existing libraries from “classic” Expectations to this version — so you get to keep all your expect forms, and just wrap them in named tests 🙂

I created it because “classic” Expectations needed custom tooling and did not work with CIDER or Cursive 🙂

And you can (expect ::some-spec (my-fn 1 2 3)) so you get Spec support built-in, which I’m pretty sure did not exist in the “classic” version…

Gotcha. One more question. IIRC I took a look at the 1.x version of your lib at one point but the semantics were a little different from the old Expectations lib, so it wasn't directly compatible. For example,

(expect
 (re-pattern "\\d+")
 "1000")

Is maintaining the same exact semantics as legacy Expectations a project goal? Or is the expectation (pun intended) that a few tests here and there will have to be rewritten?

I would consider that a bug, if it worked in “classic” Expectations and not in the clojure.test-compatible version.

Although (re-find #"\\d+" "123") => nil so I don’t think that expectation would pass either?

(re-pattern "\\d+") -> #"\d+"

the escaped slash gets unescaped

I just double-checked, and

(expect
 (re-pattern "\\d+")
 "123")

(expect
 (if (testing-some-completely-broken-database?)
   some-form
   some-other-form)
 do-something)

Just out of curiosity, is there a reason why such functionality isn't included in malli itself yet? Future plans? @ikitommi

I'm a (positively) surprised Vase is still in use, I thought it had lost traction :)

there are at least 4 different flavours of schematized defn macros in the wild and Rich is doing/thinking something new for this. Don't wont to make any one standard now. All anyway share m=> machinery, all contribute to same registry, get clj-kondo for free etc. The Plumatic-style will be an optional part of malli, as I like the most 😎

:)

The first release of scittle is available (v0.0.1), hosted on JSDelivr: https://github.com/borkdude/scittle/releases/tag/v0.0.1 Scittle lets you evaluate ClojureScript programs in script tags, without setting up a CLJS project, via the Small Clojure Interpreter. New since the first commit: - Reagent plugin - CLJS-Ajax plugin Usage: https://borkdude.github.io/scittle Also check out this all new full stack luminus guestbook example: https://github.com/kloimhardt/babashka-scittle-guestbook

This is just… sorcery! :wizard:

SCI is eating the world

sorsciry

Very cool!

inconceivable