announcements

Project/library announcements ONLY - use threaded replies for discussions. Do not cross post here from other channels. Consider #events or #news-and-articles for other announcements.
seancorfield 2021-06-12T00:04:08.207100Z

@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.

seancorfield 2021-06-12T00:05:40.207300Z

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.

seancorfield 2021-06-12T00:06:27.207500Z

“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?

seancorfield 2021-06-12T00:07:22.207700Z

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

camsaul 2021-06-12T00:14:25.207900Z

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.

seancorfield 2021-06-12T00:17:02.208100Z

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.

camsaul 2021-06-12T00:18:12.208300Z

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

seancorfield 2021-06-12T00:19:26.208500Z

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.

seancorfield 2021-06-12T00:20:23.208700Z

(that’s how we migrated)

camsaul 2021-06-12T00:22:11.208900Z

ok, gotcha. that makes sense. thanks

seancorfield 2021-06-12T00:22:38.209200Z

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)))

seancorfield 2021-06-12T00:24:13.209400Z

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 🙂

seancorfield 2021-06-12T00:25:41.209600Z

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

seancorfield 2021-06-12T00:26:58.209800Z

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…

👍 1
camsaul 2021-06-12T00:34:05.210200Z

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#L381

camsaul 2021-06-12T00:42:22.210500Z

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?

seancorfield 2021-06-12T00:53:40.210900Z

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

👍 1
seancorfield 2021-06-12T00:55:38.211200Z

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

camsaul 2021-06-12T00:56:59.211400Z

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

camsaul 2021-06-12T00:57:12.211600Z

the escaped slash gets unescaped

camsaul 2021-06-12T01:08:44.211800Z

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 evaled

borkdude 2021-06-12T15:04:38.217800Z

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

16
❤️ 6
🚀 18
8
🎉 39
4
eggsyntax 2021-06-14T13:55:05.234200Z

Wheeeee! :awesome:

seancorfield 2021-06-12T15:35:47.219300Z

This is just… sorcery! :wizard:

henrik 2021-06-12T17:32:13.220400Z

SCI is eating the world

1
➕ 6
🎉 3
nate 2021-06-12T17:40:06.220900Z

sorsciry

😆 13
2021-06-12T18:13:43.221400Z

Very cool!

bherrmann 2021-06-12T23:03:35.222800Z

inconceivable