Hi Timothy,
Many thanks for taking the time to look into fudje...It is nowhere near
as mature as midje but I find it pretty neat and a pleasure to work with
so far (apart from the 'multimock' workaround perhaps). Also, many
thanks for your feedback...It seems you have misunderstood the purpose
of sweet.clj though...The sole purpose of that file is to help you
auto-migrate your existing midje code to fudje (which is much closer to
clojure.test). If you don't have any existing midje tests, then there is
no reason to ever look at fudje/sweet.clj. You need to `require` it if
you want to use the checker-stuff, but other than that, noone forces you
to use `fact` or `tabular`, and in fact it would be weird if one did.
These are purely there to support automatic rewrite. It has worked for
us nicely where i work...For the most part changing the ns declaration
is enough to 'un-midje' an entire namespace (some limitations exist of
course). I hope that is clearer now...fudje introduces no new syntax,
other than the `=>` which IMO nicely/visually separates the mock-outs
from the mock-ins (i think that was a good decision made by midje in the
first place and kept it).
Now, your other point, i actually understand, and believe it or not, i
agree! for example at work we've talked this through and we're only
opting in for this stuff when it's actually adding value - not for every
single test case. I'll admit that example is a bit contrived and not
very welcoming, but i was sort of trying to cram as much stuff as
possible in the tests (where the demos are from). Actual usage of fudje
almost never looks like that cryptic, and if it does it mostly has to do
with checker abuse rather than new syntax. Your little snippet actually
tests less stuff with more code, and of course, no mocks, but I do get
the point that 'more code' isn't actually a problem when the code is
clearer. :) I'm with you on this one
I guess at the end of the day if i want to support arbitrarily nesting
checkers, there will always be a possibility for some very ugly code.
apart from the `=>` symbol, which BTW can be anything you like as it's
never evaluated, I don't see where you get the DSL impression from.
fudje was specifically designed top to bottom to be as less sugary as
possible (even though fudge is very very sugary!). :)
Kind regards,
dimitris
On 27/01/16 20:46, Timothy Baldridge wrote:
So a bit of constructive feedback on Fudje, firstly, I like that it's
pretty simple, I can take bits I want and leave bits I don't, so good
work on that.
But I do have a issue with the sweet.clj syntax, and I think it's best
exemplified by the code found in the intro:
(testing "arg-checker in mocking vector"
(mocking [(f (just {:a (contains [2 3])
:b (has every? keyword?)})) => :some-number]
(is (= :some-number (f {:a [1 2 3 4] :b #{:x :y :z}})))))
This is a good example of a DSL, and it falls under the criticisms I
level at most DSLs, mainly they aren't Clojure. If we dive into
sweet.clj and the surrounding namespaces we see a good example of a
parser (from clojure to a AST) and a execution engine (via the
protocols). You wrote a programming language, congrats!
But with that DSL comes some baggage, it's no longer Clojure. Now my
code is written in one language and my tests in another. I must now go
and read the Fudje docs to understand the syntax and the evaluation
order/semantics. I know these are mostly taken from Midje, but that's
one of my criticisms about that library as well.
Instead, I would prefer to just use something like the following
(testing "arguments are sane"
(is (contains (:a input) [2 3]))
(is (every? keyword? (:b input))))
Now any Clojure programmer that comes after me can easily understand
what's going on, since everything is written in the same language.
There's still room for more advanced testing predicates, and even the
mocking macro may have its place. But I'd recommend dropping the DSL.
Timothy
On Wed, Jan 27, 2016 at 12:47 PM, dimitris <jimpil1...@gmail.com
<mailto:jimpil1...@gmail.com>> wrote:
Hi Brian,
Thanks for your kind words and, of course, for midje...I've been
using it for years!
About the AOT issues, i was mainly referring to this:
https://github.com/marick/Midje/issues/274
In addition, where i work we have to package our 'harness-testing'
module separately and not AOT it. That has generally worked
nicely, and taking a step back it seems like good practice to
package all your testing infrastructure separately, but the fact
that we can't is unfortunate nonetheless. Has something changed in
terms of this issue that I'm not aware of? If yes, please forgive
me for 'misleading'- i will fix asap!
Thanks again...
Cheers,
dimitris
On 26/01/16 23:42, Brian Marick wrote:
dimitris wrote:
This is a small testing library inspired by midje.
For what it's worth, I (author of Midje) think this is wonderful.
You might consider emphasizing that you have similar checkers,
as I think that's one of Midje's strong points. I've been
recently incorporating
https://github.com/marick/structural-typing/ to get better
error messages when checking collections. Like this:
The checker said this about the reason:
[0 :a :b] should be `even?`; it is `1`
[1 :c] must exist and be non-nil
[2 :a :b] should be `neg?`; it is `2`
Otherwise:
1) The implementation is utterly intimidating (i' ve heard
this from
plenty other people)
Yeah. It started as my project to learn Clojure, so it's
not... um... the way I write code today.
2) Doesn't play nicely with AOT
At two companies, I've used Midje and deployed AOT-compiled
uberjars. It would be interesting to have a specific example
of the problem.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<mailto:clojure@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+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@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+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
