Fork me on GitHub

@nberger: We're using Speclj, my coworker wrote it and our app was the first project it was used in, like a testing ground.


@sdegutis cool. Are you happy with it? I see it has its own assertion fns/macros (should, should-not)... Do you sometimes have to use clojure.test or you can "do everything" with speclj?


Also: does lein spec run clojure.test tests, or just specs?


@nberger: We use Speclj exclusively, so we only run our specs. I only use describe, it, and should=, I don't make use of any other Speclj features.


@nberger: For the most part, I really like how the output is formatted, it reminds me of RSpec a lot. I haven't found any other testing framework's output to be as nice.


@nberger: There are a few bugs I encounter sometimes in our codebase, but they've been closed in the Speclj repo as "cannot reproduce" which gives me little hope they'll be fixed.


@sdegutis: Have you tried clojure.test + humane-test-output? It's a great improvement from plain clojure.test

nberger12:08:09 has a nice comparison of output from different testing libraries, it's more than 1 year old but I guess not much has changed


From the comments I see that when the author wrote it, he didn't know about should== in speclj, so the comparison is not 100% fair on speclj. But at the same time, it's a pitty that you have to use a different fn to get a nice deep comparison


@nberger: Thanks for the tip, I'll look into that.


@nberger: Do you use an auto-test-re-runner for clojure.test?


Not for clojure.test, yes for cljs.test.


For clojure.test, most of the times I run the tests in the repl, using keyboard shortcuts, and I'm happy with that, most of the times simple_smile


We have the entire server (top to bottom) tested in what could be considered half-unit / half-integration tests. So anytime we make a change in any line of code, it's useful to run any tests that may be affected (sometimes almost all of them).


Yes, that's nice... except when it's difficult to say which tests may be affected, or when you don't want to wait for the entire test suite to run


Many times when I had autotest workflows setup and working, mostly with rspec+guard, I wanted to turn it off, because it would run more tests than I wanted to


Likewise, many times tests failed in unexpected parts of my code due to a bug in my changes.


Yes. Or perhaps your test suite takes more than say 2 seconds (or 2 minutes :/). I like it more to have easy ways to run a specific test, an entire test file, or the entire suite, at the tip of my fingers


I like that blog post.


I guess we should invite @jakemcc here simple_smile


@sdegutis: glad to hear it


its a bit dated by now, could probably refresh it and also show Flare


though, besides that I’m not sure if test output has really changed much in the last year


@jakemcc: didn't know about flare, will check it out later, thanks


no problem. I still prefer humane-test-output but use flare on one project just to keep an eye on it


@nberger: if you end up trying Flare, I’d recommend using (install {:expected :first}) to bring it inline with what humane-test-output and clojure.test documenation show about expected vs actual ordering in assertions.


I would have liked Expectations the best, except that it doesn't allow me to give my tests string-descriptions and see these in the output.


I would have liked clojure.test with humane-test-output second-best, except that it only lets me name tests with valid symbols, not strings.


@jakemcc: You didn't mention color in your blog post. humane-test-output isn't colorizing my output 😢


@sdegutis: yeah, probably shows my bias towards not paying attention to color. At this point I only even look at output if there is a failure


Me too, but red is a quick indication that there's an error when 700 test results are flying by.


@sdegutis: not sure if you’re using lein-test-refresh for auto-running, but if you do you can silence the noisy clojure.test output with a configuration flag.


so much nicer


@jakemcc: I haven't used any of these auto-refreshers for clojure.test because of


@jakemcc i.e. there are three very similar libs that implement certain critical aspects of their purpose slightly differently and it's not obvious what the strengths and weaknesses of each approach are, which makes me hesitant to choose any single one out of fear of locking myself into one that has headaches and bugs


luckily you aren’t really locked into anything since (as far as I know) nothing about any of them requires you to change anything about your code except for adding something to your project.clj


I’m obviously biased in that I think lein-test-refresh is the one people should use, but I’m actually more pro someone using any autorunner