This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (38)
- # babashka (5)
- # beginners (26)
- # calva (26)
- # cider (1)
- # clj-kondo (36)
- # cljdoc (17)
- # cljs-dev (31)
- # clojure (39)
- # clojure-australia (9)
- # clojure-berlin (2)
- # clojure-dev (31)
- # clojure-europe (22)
- # clojure-france (3)
- # clojure-italy (7)
- # clojure-nl (5)
- # clojure-norway (5)
- # clojure-spec (28)
- # clojure-uk (9)
- # clojured (20)
- # clojurescript (24)
- # community-development (2)
- # conjure (32)
- # core-async (7)
- # cryogen (6)
- # datomic (2)
- # duct (6)
- # fulcro (6)
- # graalvm (53)
- # introduce-yourself (2)
- # jobs (2)
- # luminus (2)
- # nrepl (2)
- # off-topic (35)
- # re-frame (17)
- # reveal (8)
- # shadow-cljs (27)
- # testing (2)
- # xtdb (8)
Hi folks, I just published a new version of https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/readme after a one-year break. This new version adds support for https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/aggregate-queries & https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/attributes#one-to-one relationships. I've also added documentation for https://cljdoc.org/d/org.graphqlize/honeyeql/0.1.0-alpha36/doc/debugging-troubleshooting.
Expectations — an expressive,
clojure.test-compatible testing library — has a prerelease of 2.0.0 available: https://cljdoc.org/d/com.github.seancorfield/expectations/2.0.0-alpha2/doc/readme — the main changes from the previous version (1.2.1) are:
- improve “drop-in” compatibility with
clojure.test (by re-exporting several
clojure.test features so you don’t need to require that as well as Expectations)
cljs.test-style fixtures (hash map with
:after functions) in addition to the regular
- provide standalone (self-hosted) ClojureScript compatibility (via
planck, thanks to @kkinear) — previously, Expectations was Clojure-only
- moves to
Follow-up in #expectations for specifics or #testing for general stuff.
Out of curiosity, are you still using Expectations yourself? We recently finished migrating ~60k lines of expectations-based tests in Metabase to
clojure.test earlier this year, mostly because there's better tooling around it.
This was easy to accomplish piecemeal by writing removing the dependency on
expectations and writing
(expect ...) https://github.com/metabase/metabase/blob/release-x.38.x/test/expectations.cljthat expanded out to a
and then defining a
(deftest some-name-based-on-test-hash (expect= expected actual))
expect=. The main reason I'm asking is 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. So if I were to convert another project using Expectations 1 (I still have a few around actually), would it really make sense to convert it to Expectations 2 instead of just converting it to
@U42REFCKA 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
“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
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
I could rewrite that as
(expect 1000 (inc 999))
(deftest my-test (is (= 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
(defexpect my-test (expect 1000 (inc 999)))
assert-exprthat 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.
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,
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
(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
(re-find #"\\d+" "123") =>
nil so I don’t think that expectation would pass either?
I just double-checked, and
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 (re-pattern "\\d+") "123")
I think basically anywhere where the
(expect (if (testing-some-completely-broken-database?) some-form some-other-form) do-something)
expectedform has any sort of logic doesn't work with the macro-based
expectapproach. I ended up just writing an
assert-exprmethod that does appropriate comparisons/assertions after the expected form is evaled
Hi all, wanted to share https://github.com/nytimes/vase.elasticsearch This adds Elasticsearch bindings to Vase so that you can build out simple search systems in a data-driven manner. We currently use it to power the NYT cooking search as well as some internal search systems.
Sounds interesting. Would you mind giving us the elevator pitch? For the initiated…
@U055DUUFS sure! this follows on the same basic premise as https://github.com/cognitect-labs/vase/blob/master/docs/design.md: a concise way to specify simple microservices for some business need. this library extends vase to add support for elasticsearch so that you can add search to a microservice or make a full search oriented microservice. we use this internally so that small teams can spin up search for their product without having to have deep knowledge about running the entirety of a search system. so we take care of the infra and the data sources and let product teams create these concise specifications of search for their business domain
Initial public release of
snoop — use malli schemas to instrument functions and validate inputs & outputs at runtime.
• Compatible with both Clojure and ClojureScript
• Convenient schema notation or use
• Works with multi-arity functions
• Configuration options for runtime and compile-time
• Uses a custom
defn wrapper macro that hopes to be easier to combine with other
I've found instrumentation to be very helpful in tracking down errors in data-heavy situations.
Just out of curiosity, is there a reason why such functionality isn't included in malli itself yet? Future plans? @U055NJ5CC
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 😎
I've updated the library to allow specifying schemas next to each parameter declaration, like you can with Plumatic. Personally, I'm not terribly keen on peppering the params vector with
:- and commas, so I decided on lists instead:
(>defn fun [(x int?) (y int?) (z melon?)] [=> string?] ...)
@U016JRE24NL One benefit of using the Schema notation would be that the syntax is supported out of the box with clj-kondo :)