@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))
I could rewrite that as clojure.test
as
(deftest my-test
(is (= 1000
(inc 999)))
or as
(defexpect my-test
(expect 1000
(inc 999)))
the effort involved in migrating such a test seems roughly equivalent. For a few cases where Expectations has different semantics, you could just write your own assert-expr
that behaves the same way as Expectations used to, e.g. for comparison against regexes or Exception classes, so for converting several hundred or thousand tests it wouldn't make a huge difference.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")
passes in "classic" Expectations, but in the new lib it doesn't (or at least didn't) because it's macro-based and the expected form isn't a regular expression yet at macroexpansion time. I don't know if that's been fixed or not yet, but at a glance it still looks like you'd run into the same thing https://github.com/clojure-expectations/clojure-test/blob/develop/src/expectations/clojure/test.cljc#L381Is 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")
definitely passes on old-school legacy classic traditional Expectations. I think there were a few other related test failures I ran in to last time I tried it. For example in Metabase we had a lot of places where we wrote tests that ran against different databases (e.g. Postgres/MySQL/H2/Oracle/SQL Server/etc.) depending on which CI node we were on e.g.
(expect
(if (testing-some-completely-broken-database?)
some-form
some-other-form)
do-something)
I think basically anywhere where the expected
form has any sort of logic doesn't work with the macro-based expect
approach. I ended up just writing an assert-expr
method that does appropriate comparisons/assertions after the expected form is evaledThe 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
Wheeeee! :awesome:
This is just… sorcery! :wizard:
SCI is eating the world
sorsciry
Very cool!
inconceivable