Midje style assertions for clojure.test
Clojars dependency:
Status: Deprecated.
Goals:
=>
and =not=>
clojure.test
Non-goals:
with Midje:
(ns some.midje.tests
(:require [midje.sweet :refer :all]))
(facts
(+ 1 2) => 3
{:a 1 :z 1} => (contains {:a 1}))
with testit
:
(ns example.midje-example
(:require [clojure.test :refer :all]
[testit.core :refer :all]))
(deftest midje-impersonation
(facts
(+ 1 2) => 3
{:a 1 :z 1} =in=> {:a 1}))
The fact
macro generates a clojure.test/is
form with the arrow in
place of test function.
(macroexpand-1 '(fact (+ 1 2) => 3))
=> (clojure.test/is (=> 3 (+ 1 2)) "(+ 1 2) => 3")
The testit
extends basic clojure.test/is
functionality
by adding appropriate assertion logic for =>
, =not=>
, =in=>
,
and =throws=>
symbols.
The facts
allows grouping of multiple assertions into a single form. For
example:
(deftest group-multiple-assertions
(facts "simple match tests"
(+ 1 2) => 3
(* 21 2) => 42
(+ 623 714) => 1337))
=>
and =not=>
arrowsThe left side of =>
arrow is a form that is evaluated once. The right side
can be a simple form that is also evaluated once. Test is performed by
comparing the evaluated values for equality (or non-equality in case of
=not=>
).
(deftest simple-form
(facts
(* 21 2) => 42))
The right side of =>
can also be a predicate function. In that case the
test is performed by passing the value of the left side to the predicate.
(deftest function-predicate
(facts
(* 21 2) => integer?))
A common practice is to call function that returns a predicate. For example:
(deftest generate-predicate
(facts
(* 21 2) => (partial > 1337)))
A bit more complex example:
(defn close-enough [expected-value margin]
(fn [result]
(<= (- expected-value margin) result (+ expected-value margin))))
(deftest function-generating-predicate
(facts
(* 21 2) => (close-enough 40 5)))
=throws=>
arrowThe =throws=>
arrow can be used to assert that the evaluation of the left side
throws an exception. The right side of =throws=>
can be:
java.lang.Throwable
java.lang.Throwable
If the right side is a class, the assertion is made to ensure that the left side throws an exception that is, or extends, the class on the right side.
(fact "Match exception class"
(/ 1 0) =throws=> java.lang.ArithmeticException)
You can also use an exception object. This ensures that the exception is of correct type, and also that the message of the exception equals that of the message on right side.
(fact "Match exception class and message"
(/ 1 0) =throws=> (java.lang.ArithmeticException. "Divide by zero"))
Most flexible case is to use a predicate function.
(fact "Match against predicate"
(/ 1 0) =throws=> #(-> % .getMessage (str/starts-with? "Divide")))
Finally, =throws=>
supports a sequence. The thrown exception is tested
against the first element from the seq, and it's cause to the second, and
so on. This is very handy when the actual exception you are interested is
wrapped into another exception, for example to
java.util.concurrent.ExecutionException
.
This example creates an java.lang.ArithmeticException
, wrapped into a
java.lang.RuntimeException
, wrapped into a
java.util.concurrent.ExecutionException
.
The fact
then tests that the left side throws an exception that extends
java.lang.Exception
and has a message "1"
, and that is caused by another
exception, also extending java.lang.Exception
with message "2"
, that is
caused yet another exception, this time with message "3"
:
(fact
(->> (java.lang.ArithmeticException. "3")
(java.lang.RuntimeException. "2")
(java.util.concurrent.ExecutionException. "1")
(throw))
=throws=> [(Exception. "1")
(Exception. "2")
(Exception. "3")])
A common pattern with Clojure code is to generate exceptions with
clojure.core/ex-info
. To help testing these kind of exceptions, testit
provides a function testit.core/ex-info?
. The function accepts a message
(string or a predicate) and a data (map or a predicate), and returns a predicate
that tests given exception type (must extend clojure.lang.IExceptionInfo
),
message and data.
(fact "Match ex-info exceptions"
(throw (ex-info "oh no" {:reason "too lazy"}))
=throws=>
(ex-info? "oh no" {:reason "too lazy"}))
The above test ensures that the left side throws an ex-info
exception with
expected message and data.
any
The any
is a predicate that matches anything. It's implemented like
this:
; in ns testit.core:
(def any (constantly true))
truthy
and falsey
Other helper predicate are testit.core/truthy
and testit.core/falsey
which test given values for clojure 'truthines' and 'falsines' respectively.
=eventually=>
arrowYou can use the =eventually=>
arrow to test async code.
(let [a (atom -1)]
(future
(Thread/sleep 100)
(reset! a 1))
(fact
(deref a) =eventually=> pos?))
On the code above, the result of evaluating the (deref a)
is initially -1.
The test does not match the expected predicate pos?
. How ever, the
=eventually=>
will keep repeating the test until the test matches, or a
timeout occurs. Eventually the future resets the atom to 1 and the test
passes.
By default the =eventually=>
keeps evaluating and testing every 50 ms and
the timeout is 1 sec. You can change these by binding
testit.eventually/*eventually-polling-ms*
and
testit.eventually/*eventually-timeout-ms*
. For example, code below sets the
timeout to 2 sec.
(testing "You can change the timeout from it's default of 1sec"
(binding [*eventually-timeout-ms* 2000]
(let [a (atom -1)]
(future
(Thread/sleep 1500)
(reset! a 1))
(fact
(deref a) =eventually=> pos?))))
=in=>
The =in=>
is for more relaxed equality tests, like contains
in Midje. For example:
(fact
{:a 1 :b 2} => {:a 1}) ;=> FAILS
(fact
{:a 1 :b 2} =in=> {:a 1}) ;=> Ok
This ensures that the actual (left side of =in=>
) contains everything the expected (right
side) contains.
contains
When given a map, =in=>
checks that all given keys are found and they match
expectations. Expected map can be nested and can contain predicates. For example:
(fact
{:a 1
:b {:c 42
:d {:e "foo"}}}
=in=>
{:b {:c pos?
:d {:e string?}}})
A very common use-case for this kind of testing is testing the HTTP responses. Here's an example.
(ns example.http-example
(:require [clojure.test :refer :all]
[testit.core :refer :all]
[clojure.string :as str]
[clj-http.client :as http]))
(deftest test-google-response
(fact
(http/get "http://google.com")
=in=>
{:status 200
:headers {"Content-Type" #(str/starts-with? % "text/html")}
:body string?}))
=in=>
When given a vector, =in=>
checks that the
expected value contains matches for each expected value, where the expected
values can be basic values or predicates. For example:
(fact
[1 2 3] =in=> [1 pos? integer?])
The matching is recursive, so this works too:
(fact
[{:a 1, :b 1}
{:a 2, :b 2}
{:a 3, :b 3}]
=>
[{:a 1}, map?, {:b pos?}])
If the expectation vector ends with symbol ...
, the actual vector can
contain more elements, they are just ignored. For example, these tests all
pass:
(facts
[1 2 3] =in=> [1 2 3 ...]
[1 2 3 4] =in=> [1 2 3 ...]
[1 2 3 4 5] =in=> [1 2 3 ...])
This does not pass:
(fact
[1 2] =in=> [1 2 3 ...]) ;=> FAILS
If the expected vector has metadata :in-any-order
, the =in=>
checks that
all expected elements are found in actual, but they are allowed to be in any
order.
(facts
[-1 0 +1] =in=> ^:in-any-order [0 +1]
[-1 0 +1] =in=> ^:in-any-order [pos? neg?]))
The =in=>
tries to provide informative error messages. For example:
(fact
{:a {:b {:c -1}}} =in=> {:a {:b {:c pos?}}})
FAIL in (failing-test) (in_example.clj:52)
{:a {:b {:c -1}}} =in=> {:a {:b {:c pos?}}}:
in [:a :b :c]:
(pos? -1) => false
expected: pos?
actual: -1
expected: {:a {:b {:c pos?}}}
actual: {:a {:b {:c -1}}}
The in [:a :b :c]
in above error message shows the path to nested element
that failed the test.
Here's another example with sequential values:
(fact
[0 1 2 3] =in=> [0 1 42 3])
FAIL in (failing-test) (in_example.clj:54)
[0 1 2 3] =in=> [0 1 42 3]:
in [2]:
(= 42 2) => false
expected: 42
actual: 2
expected: [0 1 42 3]
actual: [0 1 2 3]
Strings have special reporting:
(fact
"foodar" => "foobar")
FAIL in (failing-test) (in_example.clj:56)
foodar =in=> foobar:
(= "foobar" "foodar") => false
expected: "foobar"
actual: "foodar"
diff: ^^^
expected: "foobar"
actual: "foodar"
Here's an example with nested structures:
(fact
{:a {:b [0 1 2 {:c "foodar"}]}}
=in=>
{:a {:b [0 neg? 2 {:c "foobar"}]}})
FAIL in (failing-test) (in_example.clj:58)
{:a {:b [0 1 2 {:c "foodar"}]}} =in=> {:a {:b [0 neg? 2 {:c "foobar"}]}}:
in [:a :b 1]:
(neg? 1) => false
expected: neg?
actual: 1
in [:a :b 3 :c]:
(= "foobar" "foodar") => false
expected: "foobar"
actual: "foodar"
diff: ^^^
expected: {:a {:b [0 neg? 2 {:c "foobar"}]}}
actual: {:a {:b [0 1 2 {:c "foodar"}]}}
Note that the above message reports two errors, first at [:a :b 1]
and
the second at [:a :b 3 :c]
.
The testit
is designed to be easily extendable using plain old functions. You
can provide your own predicates, and combine your predicates with those provided
by clojure.core
and testit
.
Here's an example that combines contains
and ex-info?
:
(fact "Match ex-info exceptions with combine"
(throw (ex-info "oh no" {:reason "too lazy"}))
=throws=>
(ex-info? any (contains {:reason string?})))
This tests that the left side throws an ex-info
exception, with any
message and a data that contains at least a :reason
that must be a string.
testit
with your own arrowsYou can add your custom arrows using clojure.test/assert-expr
. For example,
here's a simple extension that asserts that the test is completed within 1 sec.
(ns testit.your-own-arrow
(:require [clojure.test :refer :all]
[testit.core :refer :all]))
(declare =quickly=>)
(defmethod assert-expr '=quickly=> [msg [_ & body]]
(assert-expr msg `(let [d# (future ~@body)
r# (deref d# 1000 ::timeout)]
(if (= r# ::timeout)
false
r#))))
And then you use it like this:
(deftest things-must-be-fast-tests
(fact
(do (Thread/sleep 200) 42) =quickly=> 42) ;=> PASS
(fact
(do (Thread/sleep 2000) 42) =quickly=> 42)) ;=> FAIL
In the example above, the first fact passes but the second fails after 1 sec.
=eventually=>
for async tests=>
forms with fact
Run tests with:
lein eftest
lein doo once
Copyright © 2017-2021 Metosin Oy.
Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.
Can you improve this documentation? These fine people already did:
Jarppe, Miikka Koskinen, Tommi Reiman, Juho Teperi & Roland ThiolliereEdit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close