clojure.test/are tabular layout for supplied parameters

[chrischambers]

Hey Kim,

I'd like the clojure.test/are macro to layout in a tabular way for the provided params, and I would guess that most people who employ it for their example-based testing would want something similar so that the arguments visually line up.

For example, the current format (with community style settings, :justified and :respect-nl) is:

(are [v k expected] (= expected (max-sum-subvector v k))
 [] 3 nil
 [1 2 3 4 5] 200 15
 [4 2 1 7 8 1 2 8 1 0] 3 16)

Ideally, I'd like it to be:

(are [v k expected]
     (= expected (max-sum-subvector v k))
 []                     3    nil
 [1 2 3 4 5]            200  15
 [4 2 1 7 8 1 2 8 1 0]  3    16)

[kkinnear]

Thanks for asking! The justification at least is easily done.

What has happened is that the default formatting for are uses variance based justification. The example that you gave has greater variance in the first column than the default allows, so it doesn't justify it. You can turn off variance based justification when formatting are by changing the invocation of the style areguide in the :fn-map for "are", as in the second example below:

(czprint i339 {:parse-string? true :style [:community :justified :respect-nl]})
(are [v k expected] (= expected (max-sum-subvector v k))
 [] 3 nil
 [1 2 3 4 5] 200 15
 [4 2 1 7 8 1 2 8 1 0] 3 16)


(czprint i339 {:parse-string? true :style [:community :justified :respect-nl] :fn-map {"are" [:guided {:style {:style-call :areguide :max-variance 1000}}]}})
(are [v k expected] (= expected (max-sum-subvector v k))
 []                    3   nil
 [1 2 3 4 5]           200 15
 [4 2 1 7 8 1 2 8 1 0] 3   16)

Getting the argument on the first line and the =expression on the second line is actually harder. I'll give that some more thought, but I wanted to get back to you quickly with the justification solution.

More later...

[kkinnear]

Regarding the third expression in the are call. If it too big for the line, it will go on the next line. If not, it stays on the first line. Given that you are using :style :respect-nl, you could put a newline before the third expression:

(czprint i339a {:parse-string? true :style [:community :justified :respect-nl] :fn-map {"are" [:guided {:style {:style-call :areguide :max-variance 1000}}]}})
(are [v k expected]
 (= expected (max-sum-subvector v k))
 []                    3   nil
 [1 2 3 4 5]           200 15
 [4 2 1 7 8 1 2 8 1 0] 3   16)

That's not exactly what you were looking for, I know.

I can certainly create an option in the "guide" that does the are formatting that will do exactly what you want. However, that will have to wait until the next release. Which isn't necessarily that far off, but will be a few weeks at least.

My question for you is -- how important is the location of the shorter third expressions? The longer ones will go on the next line, as I said before. The shorter ones are the only ones that need work. Well, and exactly how much they indent on the second line is also slightly different if they are long than you indicated that you want. So let me know what (if anything) in the third expression location is really important for you. Thanks!