Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[Timothy Baldridge]

It's also interesting to note that I most often write my clojure.test code
thusly:

(is (= (some-function some-val)
 42))

Which reads pretty much the same way, but without (many) macros.
Technically `is` is a deep walking macro, but that's more about error
reporting than DSLs.

Timothy

On Sun, Jan 31, 2016 at 9:05 AM, Brian Marick  wrote:

>
>
> Timothy Baldridge wrote:
>
>> 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
>>
>
> I note that Midje once had an intermediate “semi-sweet” functional
> interface that the `fact` macro expanded into. (It was most similar to
> Expectations’.) That’s because I was originally thinking the syntax was a
> little extreme and people would prefer something Lispy or to invent their
> own.
>
> At some point, the extra level of translation got annoying, so I asked on
> the mailing list if anyone objected to my deleting it. No one did.
>
> So there is some user demand for a DSL.
>
> And I think there’s probably a reason why /The Joy of Clojure/ and other
> books write examples in a left-right format like:
>
>  (if true :truthy :falsey);=> :truthy
>
> … rather than:
>
>  (is (= :truthy (if true :truthy :falsey)))
>
> I broadly agree with the idea of avoiding complex macros as DSLs. But
> testing - like textbooks - is a domain where understandability by someone
> new to an API is really important. So it’s a place where user experience
> might trump general principles.
>
>
> --
> 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.
>



-- 
“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.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[Brian Marick]

Timothy Baldridge wrote:

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


I note that Midje once had an intermediate “semi-sweet” functional 
interface that the `fact` macro expanded into. (It was most similar to 
Expectations’.) That’s because I was originally thinking the syntax was 
a little extreme and people would prefer something Lispy or to invent 
their own.


At some point, the extra level of translation got annoying, so I asked 
on the mailing list if anyone objected to my deleting it. No one did.


So there is some user demand for a DSL.

And I think there’s probably a reason why /The Joy of Clojure/ and other 
books write examples in a left-right format like:


 (if true :truthy :falsey);=> :truthy

… rather than:

 (is (= :truthy (if true :truthy :falsey)))

I broadly agree with the idea of avoiding complex macros as DSLs. But 
testing - like textbooks - is a domain where understandability by 
someone new to an API is really important. So it’s a place where user 
experience might trump general principles.


--
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.

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[dimitris]

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 > 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.


   

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[Timothy Baldridge]

Thanks for taking the time to reply.

Yes, let me clarify what I mean by DSL. Let's say I in my code somewhere
say:

(println (just 42))

What is printed in my repl is an instance of the JustChecker type. Calling
(just ...) doesn't do anything on its own, it constructs am Abstract Syntax
Tree (AST) of sorts that represents how a checker should check something in
the future. If we crack open the code inside JustChecker we see a method
call (diff-similar ...) that's the "eval" function of your DSL, or mini
language.

And therein likes the problem with DSLs they often have "non" clojure
semantics that are only valid inside a given context (a test runner for
example). So it becomes very hard to know where I'm allowed to use Clojure
constructs (map, filter, doseq, etc.) and where I'm in a DSL land where
only certain forms are supported. DSLs have their place, I'm just
unconvinced that a test suite is one of them.

Timothy

On Wed, Jan 27, 2016 at 4:55 PM, dimitris  wrote:

> Hi again Timothy,
>
> I just got what you meant! by DSL you mean the 'free-floating' checkers
> right? You mean that you'd prefer to see the checkers as `assert-expr`
> extensions so they are recognizable by `is` yes? I'm not entirely opposed
> to that but that would mean one `is` per assertion, which sounds
> cumbersome. I will contemplate this idea of an alternate api where `is`
> recognises individual checker symbols and if the idea matures i might
> include it as a separate namepace in fudje...Thanks again! :)
>
> Regards,
> dimitris
>
> On 27/01/16 23:40, dimitris wrote:
>
> 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 

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[Devin Walters]

Based on the way I've been using midje and the way I use clojure.test, I
really appreciate the middle path fudje has chosen. I don't think the DSL
underneath has caused any confusion, and the team I'm working with is
composed of seasoned Clojure programmers who have never used midje before.
Anecdotal as it may be, I would be remiss not to mention it.

The readability of most tests in midje far exceed the clojure.test
equivalent. So, I guess I would be wary of throwing the baby out with the
bathwater for purity's sake in fudje. No snark intended, but I am
unconvinced that a test suite _isn't_ the place for a DSL.

Aside: `(is (= (foo x) bar))` is a bummer. `(foo x) => bar` is bell clear.
I can't even begin to count the number of times I've seen test vs actual in
reverse order. Just sayin'.

On Wed, Jan 27, 2016 at 6:19 PM, Timothy Baldridge 
wrote:

> Thanks for taking the time to reply.
>
> Yes, let me clarify what I mean by DSL. Let's say I in my code somewhere
> say:
>
> (println (just 42))
>
> What is printed in my repl is an instance of the JustChecker type. Calling
> (just ...) doesn't do anything on its own, it constructs am Abstract Syntax
> Tree (AST) of sorts that represents how a checker should check something in
> the future. If we crack open the code inside JustChecker we see a method
> call (diff-similar ...) that's the "eval" function of your DSL, or mini
> language.
>
> And therein likes the problem with DSLs they often have "non" clojure
> semantics that are only valid inside a given context (a test runner for
> example). So it becomes very hard to know where I'm allowed to use Clojure
> constructs (map, filter, doseq, etc.) and where I'm in a DSL land where
> only certain forms are supported. DSLs have their place, I'm just
> unconvinced that a test suite is one of them.
>
> Timothy
>
> On Wed, Jan 27, 2016 at 4:55 PM, dimitris  wrote:
>
>> Hi again Timothy,
>>
>> I just got what you meant! by DSL you mean the 'free-floating' checkers
>> right? You mean that you'd prefer to see the checkers as `assert-expr`
>> extensions so they are recognizable by `is` yes? I'm not entirely opposed
>> to that but that would mean one `is` per assertion, which sounds
>> cumbersome. I will contemplate this idea of an alternate api where `is`
>> recognises individual checker symbols and if the idea matures i might
>> include it as a separate namepace in fudje...Thanks again! :)
>>
>> Regards,
>> dimitris
>>
>> On 27/01/16 23:40, dimitris wrote:
>>
>> 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

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[dimitris]

Hi again Timothy,

I just got what you meant! by DSL you mean the 'free-floating' checkers 
right? You mean that you'd prefer to see the checkers as `assert-expr` 
extensions so they are recognizable by `is` yes? I'm not entirely 
opposed to that but that would mean one `is` per assertion, which sounds 
cumbersome. I will contemplate this idea of an alternate api where `is` 
recognises individual checker symbols and if the idea matures i might 
include it as a separate namepace in fudje...Thanks again! :)


Regards,
dimitris

On 27/01/16 23:40, dimitris wrote:

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 > 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' 

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[dimitris]

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
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.

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[Timothy Baldridge]

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  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
> 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.
>



-- 
“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.
For more options, visit 

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[Brian Marick]

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
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.

[ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

[dimitris]

Hi everyone,

This is a small testing library inspired by midje. Before you start 
pulling your hair, about why do we need yet another unit-testing 
library, please consider reading the README and/or intro.md.


https://github.com/jimpil/fudje

TL/DR;

Midje comes with some very cool features but they come at a cost.

1) The implementation is utterly intimidating (i' ve heard this from 
plenty other people)

2) Doesn't play nicely with AOT
3) Introduces some syntax which when compared to regular clojure code 
looks a bit strange
4) Is big (counting, not just the core library but the transitive 
dependencies too)


Fudje offers the majority of features offered my midje, but addresses 
these issues. In particular:


1) The implementation is utterly straight forward. It's just  a combo of 
clojure.test, clojure.data & with-redefs

2) Fudje has no problem being AOT compiled
3) It doesn't introduce any new syntax. The main `mocking` macro 
resembles `clojure.core/binding`.
4) The core library alone is roughly 9 times smaller than midje and the 
only dependency is `clojure.math.combinatorics`.


Fudje also comes with 2 macros (`fact` & `tabular`) that will 
auto-rewrite your existing midje facts into, essentially, clojure.test 
assertions.
This allows for a smooth/ gradual migration away from midje (if that's 
what you want of course).


I hope people find this useful. :)

Kind regards,
Jim

--
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.