lazytest.extensions.expectations — io.github.noahtheduke/lazytest 1.7.0

Adapts the expect assertion and utility functions from Expectations v2.

note

As of Lazytest 1.7.0, the interface vars defexpect and expecting have been marked as deprecated and will be removed in a future version. Please require them from lazytest.experimental.interfaces.expectations if you wish to continue to use them, tho take care with them being implemented to match their original behavior.

The Expectations v2 interface vars (defexpect, expecting, etc) have also been adapted. Due to the differences in Lazytest and clojure.test, test cases must be defined with lazytest.core/it, as expect is merely an assertion.

(defexpect example-test
  (expecting "many ways to work"
    (it "is a cool assertion DSL"
      (expect 2 2))))

=? clj macro

(=? e a msg)

(=? e a form' msg)

=?-impl clj

(=?-impl {:keys [e e# a a# conform?]})

approximately clj

(approximately v)

(approximately v d)

Given a value and an optional delta (default 0.001), return a predicate that expects its argument to be within that delta of the given value.

between clj

(between a b)

Given a pair of (numeric) values, return a predicate that expects its argument to be be those values or between them -- inclusively.

between' clj

(between' a b)

Given a pair of (numeric) values, return a predicate that expects its argument to be (strictly) between those values -- exclusively.

defexpect clj macro deprecated

(defexpect n & body)

Given a name (a symbol that may include metadata) and a test body, produce a standard lazytest.core test var (using defdescribe).

expect clj macro

(expect a)

(expect e a)

(expect e a msg)

(expect e a msg ex? e')

Translate Expectations DSL to lazytest.core language.

These are approximate translations for the most basic forms:

(expect actual) => (expect actual)

(expect expected actual) => (expect (= expected actual))

(expect predicate actual) => (expect (predicate actual))

(expect regex actual) => (expect (re-find regex actual))

(expect ClassName actual) => (expect (instance? ClassName actual))

(expect ExceptionType actual) => (expect (thrown? ExceptionType actual))

(expect spec actual) => (expect (s/valid? spec actual))

An optional third argument can be provided: a message to be included in the output if the test fails.

In addition, actual can be (from-each [x coll] (computation-of x)) or (in set-of-results) or (in larger-hash-map).

Also, expect can be one of (more predicate1 .. predicateN), (more-> exp1 expr1 .. expN exprN) where actual is threaded through each expression exprX and checked with the expected value expX, or (more-of binding exp1 val1 .. expN valN) where actual is destructured using the binding and then each expected value expX is used to check each valX -- expressions based on symbols in the binding.

expecting clj macro deprecated

(expecting string & body)

The Expectations version of lazytest.core/describe.

from-each clj macro

(from-each bindings & body)

(expect expected (from-each [v coll] (f v))) -- expect this to be true for each element of collection. (f v) is the actual result.

Equivalent to: (doseq [v coll] (expect expected (f v)))

(expect even? (from-each [v (range 10)] (* 2 v)))

from-each may only be used inside expect and is a purely syntactic construct. This macro can be refer'd to satisfy tooling like clj-kondo.

functionally clj

(functionally expected-fn actual-fn)

(functionally expected-fn actual-fn difference-fn)

Given a pair of functions, return a custom predicate that checks that they return the same result when applied to a value. May optionally accept a 'difference' function that should accept the result of each function and return a string explaininhg how they actually differ. For explaining strings, you could use expectations/strings-difference. (only when I port it across!)

Right now this produces pretty awful failure messages. FIXME!

in clj macro

(in coll)

(expect expected (in actual)) -- expect a subset of a collection.

If actual is a hash map, expected can be a hash map of key/value pairs that you expect to be in the actual result (there may be other key/value pairs, which are ignored).

If actual is a set, vector, or list, expected can be any value that you expect to be a member of the actual data.

(expect {:b 2} (in {:a 1 :b 2 :c 3})) (expect 2 (in #{1 2 3})) (expect 2 (in [1 2 3]))

in may only be used inside expect and is a purely syntactic construct. This macro can be refer'd to satisfy tooling like clj-kondo.

more clj macro

(more & expecteds)

(expect (more expected1 ...) actual) -- provide multiple expectations on actual as a series of expected results.

Equivalent to: (do (expect expected1 actual) ...)

(expect (more int? even?) 42)

more may only be used inside expect and is a purely syntactic construct. This macro can be refer'd to satisfy tooling like clj-kondo.

more-> clj macro

(more-> & expected-threaded-pairs)

(expect (more-> expected1 (threaded1) ...) actual) -- provide multiple expectations on actual based on threading it into various expressions.

Equivalent to: (do (expect expected1 (-> actual (threaded1))) ...)

(expect (more-> string? (first) int? (second)) ["test" 42])

more-> may only be used inside expect and is a purely syntactic construct. This macro can be refer'd to satisfy tooling like clj-kondo.

more-of clj macro

(more-of destructuring & expected-actual-pairs)

(expect (more-of destructuring expected1 actual1 ...) actual) -- provide multiple expectations on actual based on binding it against the destructuring expression (like in a let) and then expecting things about its subcomponents.

Equivalent to: (let [destructuring actual] (expect expected1 actual1) ...)

(expect (more-of [a b] string? a int? b) ["test" 42])

more-of may only be used inside expect and is a purely syntactic construct. This macro can be refer'd to satisfy tooling like clj-kondo.

side-effects clj macro

(side-effects fn-vec & forms)

Given a vector of functions to track calls to, execute the body.

Returns a vector of each set of arguments used in calls to those functions. The specified functions will not actually be called: only their arguments will be tracked. If you need the call to return a specific value, the function can be given as a pair of its name and the value you want its call(s) to return. Functions given just by name will return nil.