The thing is that the Clojure test runner looks for :test in the attrs-map of defined functions and runs them. Here’s a super simple example:
(defn abs
"The absolute value of a number."
{:test (fn []
(is (= (Math/abs 5) 5))
(is (= (Math/abs -2) 2))
(is (= (Math/abs 0) 0)))}
[x]
{:pre [(number? x)]}
(if (pos? x)
x
(- x)))
I think this has lots of advantages. Keeping the (or at least, some) tests with the software under test makes for good documentation, promotes keeping the tests updated and is generally convenient.
With Clojure it gets extra powerful since you can use the REPL to grow the tests and the code you are testing without having to open some other file or window. I sometimes find myself entering a flow where I sort of mix REPL and test driven development. So instead of doing my experiments in the REPL window or even in a comment block I carry them out in that attrs-map, and then some of the experiments can just stay as tests.
It might not be for everyone, or for every occasion, but I recommend giving it a try. You might like it!
EDIT. In the original post I said this doesn’t work in ClojureScript. It does. See below. (I don’t know why it didn’t work when I tried this some while ago. It certainly wasn’t for lack of trying…)
FWIW I never do this and wouldn’t recommend doing it either.
When I write test I keep them separate since quite often the tests will become longer than the actual implementation, as your example already shows. Oftentimes the “tests” will require additional dependencies which would polute the original ns if done inline.
Yeah, the ratio of test code/tested code is often > 1. I don’t see it as problematic, though.
This certainly happens, and when it does I often move those tests out to a test namespace. It’s one of those reasons why ”(or at least, some) tests”. I also know of people who have written large and successful apps without worrying about the extra dependencies in the tested namespace.
(defn test-var
"If v has a function in its :test metadata, calls that function,
add v to :testing-vars property of env."
[v]
(run-block (test-var-block v)))
@PEZ if you tested this on older versions of shadow-cljs it might indeed not have worked. I changed it a little while ago, so previously it did indeed not account for :test metadata.
I do something like this all the time! Not exactly inline tests, but I like keeping the test code in the same block when I’m developing.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Step 1
;;
;; I like to be able to C-c C-c on the block to see where
;; I'm at. So I evolve the function definition and the test
;; in sync.
(do
(defn three []
(+ 1 1))
[(three)
(= (three) 3)]
)
;; => [2 false]
;; Not right -- work on it till it makes sense.
(do
(defn three []
(+ 1 1 1))
[(three)
(= (three) 3)]
)
;; => [3 true]
;; there!
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Step 2a
;;
;; Small functions. Document the function interface with an
;; example in the docstring.
(defn three
"Produce the number three
(three)
;; => 3
"
[]
(+ 1 1 1))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Step 2b
;;
;; Larger functions. Make a proper test!
;; math.clj
(defn three
"Produce the number three"
[]
(+ 1 1 1))
;; math_test.clj
(deftest test-three
(is (= 3 (three))))
As a counterpoint, I keep my tests with the code, usually in a deftest form right after the function. Main reasons:
They serve as documentation and a demonstration, showing behavior in corner cases (nils, empty collections, etc)
Tests which live in a separate file structure tend to get rusty over time
As to dependencies, since I only write unit tests, there are no dependencies.
I’m not saying this is the One True Way, I just wanted to point out that separating tests from code is not necessarily the One True Way either. There are many approaches to writing tests.
