testing platform , midje or specjl ?

[Roelof Wobben]

Hello,

Im learning clojure as the beginnner.

When im googeling for a testing platform there seems to be two major choices midje and specjl.

Now I see that my learning course from github uses midje.

Can I better learn midje and it this one still active maintained or can I better learn specjl.

Roelof

[Brian Marick]

On Oct 26, 2014, at 12:51 PM, Roelof Wobben <rwo...@hotmail.com> wrote:

> Can I better learn midje and it this one still active maintained or can I better learn specjl.

I've fallen behind on Midje maintenance (and, indeed, many things other than work). I'm gradually ramping up again with ideas gained in a year and a half of daily use.

For learning Clojure, I think any testing framework will suit you well.

--------
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

[Ashton Kemerling]

Don't forget clojure.test! It's simple, but I've found it to be sufficient. 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cameron]

Id' second clojure.test, 

  it's simple, tests are written in idiomatic clojure and has good tooling support (eg. run tests in cider).

It's my go-to testing library now.

[Reid McKenzie]

Have another +1 for clojure.test. It’s packaged with Clojure and while it’s not especially shiny I find that it gets the job done most of the time in addition to having the best tooling support.

In my latest project, I’ve been enjoying using org.clojure/test.check, arguably the most active of the QuickCheck clones for Clojure. I’ve been very happy with it, especially when paired with lein-cloverage to report on test coverage. It’s been …. interesting to say the least to be able to watch how the tests I write compare to the actual code paths I write. Many corner cases now covered and eliminated as a result. By way of example: a trivial recursive decent parser: https://github.com/oxlang/oxlang/blob/master/src/oxlang/parser.clj and test.check test coverage: https://github.com/oxlang/oxlang/blob/master/test/oxlang/parser_test.clj. Note that the (defspec) form is a macro that emits clojure.test test handles for test.check properties, so you can get the best of both :D.

Reid

[Ashton Kemerling]

I'd forgotten to mention Test.Check, thanks Reid!

I've had really great luck using test.check (and Doublecheck, the cljx
port) for testing both Clojure(script), Javascript, and Ruby
(integration style). Highly recommend.

On 10/26/2014 08:28 PM, Reid McKenzie wrote:
> Have another +1 for clojure.test. It’s packaged with Clojure and while
> it’s not especially shiny I find that it gets the job done most of the
> time in addition to having the best tooling support.
>
> In my latest project, I’ve been enjoying using org.clojure/test.check

> <https://github.com/clojure/test.check>, arguably the most active of the

> QuickCheck clones for Clojure. I’ve been very happy with it, especially

> when paired with lein-cloverage <https://github.com/lshift/cloverage> to

>> <javascript:>

>> Note that posts from new members are moderated - please be
>> patient with your first post.
>> To unsubscribe from this group, send email to

>> clojure+u...@googlegroups.com <javascript:>

>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> <http://groups.google.com/group/clojure?hl=en>
>> ---
>> You received this message because you are subscribed to the
>> Google Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from

>> it, send an email to clojure+u...@googlegroups.com <javascript:>.

>> For more options, visit https://groups.google.com/d/optout

>> <https://groups.google.com/d/optout>.

>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient
>> with your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to clojure+u...@googlegroups.com

>> <mailto:clojure+u...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>
> ​
>

--

Ashton

[Gary Verhaegen]

For example-based testing, i really like expectations. I think it pushes in the right direction (simple, functional), and has good enough tool support (lein-autoexpect, and a pretty trivial way of running tests in both Eclipse and Maven, which is great for the mostly Java environment I work in).

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Aleš Roubíček]

Every library is good for different kinds of testing. If you like BDD style go with Speclj, if you want to do acceptance testing with table like data go with Midje. If you preffer test after go with expectations or clojure.test. Test.Check is good addition to test toolbelt for everyone.

[Colin Yates]

Hi Roelof,

I have used midje for a few years now and it is excellent. It was the first one I picked up.

However, I would recommend clojure.test *whilst learning* for a few reasons:

- it is sufficient

- it is opinionated and therefore keeps you on the straight and narrow

- it is (probably) the best supported in terms of IDE support (emacs and CIDER for example)

Midje is great, it really is. And although I haven't used any of the others (although I have looked at them and am very familiar with BDD) I am sure the same could be said of them. However, for me the question is one of focus and guidance. 

Part of midje's greatness is its flexibility. It supports top down, bottom up, makes mocking easy etc. None of which helps when the problem being solved is "how do I do this *idiomatically*". clojure.test is much more opinionated, so if you are fighting the tool then that is a big flag that you might be doing something wrong right there. I picked up Midje for example and it allowed me to carry on writing OO code far longer than I should have. Had I used clojure.test then I wouldn't have had to fight some small incidental complexity battles (junit integration for example) and would have lost other battles I shouldn't have won (if you see what I mean).

Ultimately, there are no wrong choices here - they are great.

If it helps, I am starting a new project and starting off with clojure.test to see how far that gets me. This is more to do with "grass is greener" than anything else :).

[Roelof Wobben]

Hello Colin,

Do you know any good tutorials about learning clojure.test. ?

Roelof

Op dinsdag 28 oktober 2014 10:16:19 UTC+1 schreef Colin Yates:

[Colin Yates]

I don't off the top of my head but http://clojuredocs.org/clojure.test
and https://clojure.github.io/clojure/clojure.test-api.html should be
enough.

I seem to remember one of the clojure books included a chapter on them.

I am sure someone else on this group will offer a better resource.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---

> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/K8tFc2jrP5I/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Steve Ford]

Hi Colin

I'm a beginner, and I started with midje.  But I was very interested to read your thoughts about clojure.test being more opinionated.  Since I'm still learning, I suspect I would benefit from clojure.test's encouragement to be more idiomatic.

However, one thing I absolutely love is midje's autotest.  I love writing out my editor and having the tests run immediately in another window.  No more bugs of the form, "Oh, this is just a simple, obvious change; no need to re-run tests."

Is there anything like that which could be done with clojure.test?

Thanks!

Steve

[Colin Yates]

Hi Steve,

https://github.com/technomancy/leiningen/wiki/Plugins has a few listed.

There is also the non-specific https://github.com/weavejester/lein-auto as well.

Hope this helps, and good luck testing!

Colin

[Colin Yates]

As a P.S. I did say it was more opinionated,  but on hindsight I am not sure that is the right phrase. I meant that it was intentionally simple so there was less room to hang yourself as oppose to midje which is excellent but can more easily accommodate poor behaviour. 

For example, in the early days I was particularly susceptible to writing functions which did too much and called too many other functions. With Midje, mocking these other functions was trivial, on hindsight a bit more pain would have been a helpful smell.

I guess you can misuse any tool, and it was my insufficiency not Midje, but sometimes removing the choices is a good thing.

[Brian Marick]

On Nov 15, 2014, at 3:52 PM, Colin Yates <colin...@gmail.com> wrote:

> For example, in the early days I was particularly susceptible to writing functions which did too much and called too many other functions. With Midje, mocking these other functions was trivial, on hindsight a bit more pain would have been a helpful smell.

I'm susceptible to that, too - still figuring it out. The terminology Midje uses, which is supposed to be reminiscent of facts that are true if subsidiary prerequisites/lemmas are, was intended to help. If the `prerequisite` or `provided` form says something interesting about the domain, it's more likely to be useful than if it's just something that makes the test easier to pass.

After about a year and a half of daily use of Midje on production code, I'm finding my style is to be mock-heavy on early iterations, reducing the number as new requirements force rework of the tests and code.

[Steven Degutis]

There's more to it than just style differences. Some of them have
capabilities and offer functionality that others don't have, which may
push you towards using such a one if you have a real need for those
features.

Disclaimer: I'm one of the maintainers of Speclj, which we use it at
work, and which my colleague and friend wrote, so I may be a bit
biased.

-Steven

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---

> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an