This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-18
Channels
- # announcements (1)
- # babashka (17)
- # beginners (26)
- # calva (7)
- # clj-kondo (57)
- # cljdoc (8)
- # clojure (6)
- # clojure-europe (26)
- # clojure-italy (1)
- # clojure-nl (1)
- # clojure-norway (52)
- # clojure-uk (4)
- # datahike (1)
- # emacs (16)
- # events (1)
- # hyperfiddle (24)
- # introduce-yourself (1)
- # jobs (8)
- # lsp (6)
- # malli (9)
- # membrane (38)
- # missionary (5)
- # polylith (26)
- # portal (4)
- # reitit (1)
- # releases (7)
- # remote-jobs (1)
ayyyyy that looks great
And one for the other way around 😄 https://github.com/magnars/kaocha-noyoda
@U9MKYDN4Q it will be configurable with {:position :last}
:)
This is kind of an interesting case though: https://twitter.com/borkdude/status/1769744216974901356
Interesting. Would probably be cool if clj-kondo could expand threading macros, as those could mess with several linters I guess?
is-eq-order
in splint only checks is
calls
but that is the problem: the value you write here is the last one, but cosmetically it is the first one
I guess the point of the lint rule is to help you get meaningful output from the test runner. As such, this is actually a mistake, and should probably be rewritten (e.g. the linter is correct)
i don't think this matters much outside of is
assertions
well, I do like to read the expected value first in all cases, but yeah it only technically matters inside of clojure.test/is etc
user=> (let [x -1] (is (< 1 x)))
FAIL in () (NO_SOURCE_FILE:1)
expected: (< 1 x)
actual: (not (< 1 -1))
false
absolutely. i just wrote the splint rule for =
because that's been my experience with eftest/kaocha/etc
well, even if you reverse it, you will get a good message right?
FAIL in () (NO_SOURCE_FILE:1)
expected: (< x 1)
actual: (not (< 1 1))
given:
(deftest example
(let [expected {:a 1}]
(is (= expected {:a 6}))))
with kaocha:
Expected:
{:a 1}
Actual:
{:a -1 +6}
1 tests, 1 assertions, 1 failures.
vs
(deftest example
(let [expected {:a 1}]
(is (= {:a 6} expected))))
and
Expected:
{:a 6}
Actual:
{:a -6 +1}
1 tests, 1 assertions, 1 failures.
it's just about what's printed in the "expected" vs "actual" logs
matcher-combinators cares about this
sure, but the community has standardized around putting the expected value first. this is purely a style lint for test output prettiness
I think so too. btw I don't get the problematic difference between kaocha example 1 and 2, can you explain it to me
I'd say it's not so much about "prettiness" as it is about clear communication of what failed
(deftest example
(let [expected {:a 1}]
(is (< 2 1))))
expected: (< 2 1)
actual: (not (< 2 1))
kaocha only cares about =
, i don't know about others
btw when I did my first clojure project in a company once, I also wrote (= x 10)
and my then colleague told me to write (= 10 x)
(2013, long before those other test runners). So I think this preference of style may also have come from other programming languages/cultures, somewhere. Since then I just stuck with it
And I do think the semantic significance is important. Which is why I use a plugin, as opposed to just flipping the order and not caring about the output.
splint has a performance rule about using .equals
when comparing against a string literal lol, i think that's off by default
yeah the performance rules are weird, they're all off by default because they lead to strange code
JVM:
user=> (time (dotimes [i 1000000000] (.equals "foo" "foo")))
"Elapsed time: 16.448459 msecs"
bb:
user=> (time (dotimes [i 1000000000] (.equals "foo" "foo")))

because bb uses SCI , which is a clojure interpreter and interop is based on reflection.