Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

We've figured out a way to do groups in a simple, flexible way, that allows
for probably everyone's use-cases. It requires a change to the spec and to
how runners work.

Here's an implementation similar to speclj: https://www.refheap.com/15744
And this is how clojure.test would be translated:
https://www.refheap.com/15752

Each test-fn may have a :group metadata key, pointing to a group-map.
Group-maps must contain :description, :around-each, :around-all, and
optionally its own parent :group.

Then the test-results becomes a nested list rather than a flat one. If you
hate using nested tests, you could just ignore it and make every test-fn
have no group.

The upside is that it allows (perfectly?) emulating fixtures in at least
clojure.test, speclj, and midje.

Another upside is it's all done statically, so you can for example choose
to run a test with or without its fixtures, and you can even run a test
with other fixtures if for some reason you have that need (someone said he
did but I'm not sure I believe him).

The downside is that now the spec talks about fixtures, which might limit
innovation. But maybe not, since it's just using normal static Clojure
data, which is known for very, very easily manipulated and generated.


On Wed, Jun 12, 2013 at 12:13 PM, Steven Degutis wrote:

> There's been some discussion about how nesting should work. It should
> probably be part of the spec, in a flexible and non-intrusive way. Then we
> would consider a flat suite of tests to be just nested suite that's only a
> 1-level deep.
>
> The two things we want nesting for are defining fixture-like behavior
> (around-each or around-all, etc), and reporting groups of tests together.
>
> The fixture part should almost definitely *not* be part of the spec.
> That's way too limiting for innovation. But the reporting aspect probably
> needs a chance to the spec.
>
> For fixture stuff, in speclj (rspec) parlance, you could imagine the
> describe macro, which transforms a list of it-blocks into a flat list of
> test-fns that are each wrapped inside any before/after/around functions
> given at the same level, and recursively does this with nested describe
> blocks. All this work could be done in the Definer, and no matter how deep
> the describe-nesting is, the result is always still a flat list of
> test-fns. This is a simple way to conform to the current spec while having
> fixture-like behavior. This was my plan for the speclj port.
>
> But for reporting, it's trickier. The reporter needs to see the structure
> somehow. This isn't easily faked with a flat list of test-results, so the
> test-results would have to become potentially nested. But this raises the
> question of how a flat list of test-fns produces a nested list of
> test-results.
>
> This is the part I'm totally confused about.
>
>
> On Sat, Jun 8, 2013 at 10:14 AM, Steven Degutis wrote:
>
>> Test2 is a new testing lib for Clojure, where the power is its
>> simplicity, extensibility, and a 
>> SPEC much
>> like Ring's.
>>
>> Github: https://github.com/evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with
>> the smart folks in #clojure, who were frustrated with the inflexibility of
>> existing libs, and intended this to be the spiritual successor to
>> clojure.test. We wanted something that was still simple like clojure.test,
>> but could be extended externally much more easily in case you wanted
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've
>> written one last night, 
>> test2-autorunner,
>> which took about an hour. This should give some idea of how easy it is and
>> how well-designed the SPEC was by the smart folks of #clojure. There are
>> some ideas at the bottom of the wiki, but of course any extensions are
>> encouraged.
>>
>> -Steven
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

There's been some discussion about how nesting should work. It should
probably be part of the spec, in a flexible and non-intrusive way. Then we
would consider a flat suite of tests to be just nested suite that's only a
1-level deep.

The two things we want nesting for are defining fixture-like behavior
(around-each or around-all, etc), and reporting groups of tests together.

The fixture part should almost definitely *not* be part of the spec. That's
way too limiting for innovation. But the reporting aspect probably needs a
chance to the spec.

For fixture stuff, in speclj (rspec) parlance, you could imagine the
describe macro, which transforms a list of it-blocks into a flat list of
test-fns that are each wrapped inside any before/after/around functions
given at the same level, and recursively does this with nested describe
blocks. All this work could be done in the Definer, and no matter how deep
the describe-nesting is, the result is always still a flat list of
test-fns. This is a simple way to conform to the current spec while having
fixture-like behavior. This was my plan for the speclj port.

But for reporting, it's trickier. The reporter needs to see the structure
somehow. This isn't easily faked with a flat list of test-results, so the
test-results would have to become potentially nested. But this raises the
question of how a flat list of test-fns produces a nested list of
test-results.

This is the part I'm totally confused about.


On Sat, Jun 8, 2013 at 10:14 AM, Steven Degutis  wrote:

> Test2 is a new testing lib for Clojure, where the power is its simplicity,
> extensibility, and a 
> SPEC much
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> with
> the smart folks in #clojure, who were frustrated with the inflexibility of
> existing libs, and intended this to be the spiritual successor to
> clojure.test. We wanted something that was still simple like clojure.test,
> but could be extended externally much more easily in case you wanted
> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
> else.
>
> This is a pre-ANN because it's more of a call for extensions. I've written
> one last night, 
> test2-autorunner,
> which took about an hour. This should give some idea of how easy it is and
> how well-designed the SPEC was by the smart folks of #clojure. There are
> some ideas at the bottom of the wiki, but of course any extensions are
> encouraged.
>
> -Steven
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Stuart Sierra]

> I don't fully understand how clojure.test's fixtures plays
> into its ability to call test functions from within other
> test functions.

They don't. Being able to call test functions within other
test functions is probably the least-designed and least-used
feature of clojure.test.

-S

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Mikera]

+1 to that! 

It would be great if there was some kind of common infrastructure from a 
tooling perspective, regardless of how the tests actually get written / 
expressed.

If I may add one more thing into the mix, it would be great if we could 
have some good way to integrate with Java testing frameworks such as JUnit. 
I maintain a small library cljunit ( https://github.com/mikera/cljunit ) 
which enables me to run clojure.test tests via JUnit in Eclipse, which is 
extremely convenient. It would be great if this kind of functionality could 
be included in future Clojure testing frameworks.

On Tuesday, 11 June 2013 13:56:44 UTC+1, Laurent PETIT wrote:
>
> You know, if some day all the test libs / frameworks can be run, test 
> results exploited, etc. through the same abstraction, this will 
> greatly ease the pain of tools developers ! 
>
> I would better write once the integration between Eclipse way of 
> running and displaying tests, than once per library ! 
>
> So ... looking forward to see this globally adopted :-) 
>
> 2013/6/11 Steven Degutis >: 
> > Timothy, Brandon, Cedric, et al.: 
> > 
> > Separating out the Discoverer from the Runner in the SPEC is a bad idea. 
> > 
> > The main benefit mentioned so far for such a separation is so we can 
> have 
> > different definitions of what constitutes a test. For example, 
> > test.generative can generate multiple tests from just one block of code. 
> > 
> > But this creates the same incompatibility problem that we already have 
> > between existing test suites. Instead, if we have a single definition of 
> a 
> > test, every definer is compatible with another. 
> > 
> > And the current definition is already flexible enough to let you 
> generate 
> > multiple tests based on one block of code, like test.generative does. 
> > 
> > 
> > On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey 
> > > 
> wrote: 
> >> 
> >> You pass not the Discoverer's results to the Runner, but the Discoverer 
> >> itself, which the Runner then invokes at need, possibly more than once. 
> >> 
> >> 
> >> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis 
> >> > 
>
> >> wrote: 
> >>> 
> >>> Originally we had Runner split into Discoverer and Runner, but I had 
> to 
> >>> combine them both in Runner again so that we can have an autorunner. 
> >>> 
> >>> Imagine that you've started your autorunner at the command line, and 
> you 
> >>> create a new test in your existing file and save it. The discoverer 
> has 
> >>> already done his role and found all existing tests and passed them to 
> the 
> >>> runner, so the runner can't see your new test, he only re-runs the 
> tests 
> >>> that existed when he first started. 
> >>> 
> >>> That's why I combined them again. So that he could re-discover all the 
> >>> tests "matching some criteria" and run them. 
> >>> 
> >>> So how do you solve this problem while separating Discoverer from 
> Runner? 
> >>> 
> >>> 
> >>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom 
> >>> > wrote: 
>  
>  There are currently 4 roles defined: Definer, Asserter, Runner, and 
>  Reporter. 
>  
>  It looks like the "Runner" does finding, filtering, and execution. I 
>  think you could further break the Runner down into Discoverer and 
> Executor. 
>  I might want to just ask "What tests do I have?" without actually 
> running 
>  anyway. I may also want a different Executor, like a 
> distributed/parallel 
>  executor, while preserving the discovery logic. 
>  
>  On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote: 
> > 
> > Test2 is a new testing lib for Clojure, where the power is its 
> > simplicity, extensibility, and a SPEC much like Ring's. 
> > 
> > Github: https://github.com/evanescence/test2 
> > 
> > Some background: It came out of discussions with the smart folks in 
> > #clojure, who were frustrated with the inflexibility of existing 
> libs, and 
> > intended this to be the spiritual successor to clojure.test. We 
> wanted 
> > something that was still simple like clojure.test, but could be 
> extended 
> > externally much more easily in case you wanted features found in 
> > clojure.test, Midje, Speclj, or Expectations, or whatever else. 
> > 
> > This is a pre-ANN because it's more of a call for extensions. I've 
> > written one last night, test2-autorunner, which took about an hour. 
> This 
> > should give some idea of how easy it is and how well-designed the 
> SPEC was 
> > by the smart folks of #clojure. There are some ideas at the bottom 
> of the 
> > wiki, but of course any extensions are encouraged. 
> > 
> > -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 
> wit

Re: [pre-ANN] test2, the last Clojure testing framework

[Brian Marick]

On Jun 11, 2013, at 2:08 PM, Tj Gabbour  wrote:

> Interesting; these arguments sound oddly like those surrounding Common Lisp's 
> "loop" macro. When reading Midje's docs, I got the weird impression Brian was 
> aware of the history of "non-lispy" macros.

I was a Common Lisp user and implementor (on the Gould PowerNode computers!) in 
the early 80's. 

However, I'm still not sure what I think of `loop`.

I like `format`, though, in practice, despite despising it in principle.


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

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Brian Marick]

On Jun 11, 2013, at 10:02 AM, JeremyS  wrote:

> Now, opinion time (more opinionated actually). Midje might be full of macros 
> and abstractions that I don't understand when I read the code. Hell it's full 
> of them. But I honestly never had to read it to write my tests. More It's 
> well documented and I there's is more functionality in the doc than I have 
> had to use. So congrats Brian.

The Midje code is more obfuscated than it should be. It is gradually improving. 
Just as I've had a goal that the Midje API should be well-documented and 
gracious towards its user, I'm starting to have the goal that the internals 
should encourage extension. Kudos to those who've contributed (especially Alex 
Baranosky and Joseph Wilk).


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

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Michał Marczyk]

On 12 June 2013 00:08, Steven Degutis  wrote:
> Right now they both point to test2.api.asserters/*assertion-results*. But
> I'd really like to get rid of the concreteness of this if possible. But even
> throwing exceptions to indicate assertion results won't do, because the
> specific exception class to throw/catch is still too concrete.
>
> Anyone have any ideas?

Use ex-info / ex-data? (NB. ex-info optionally takes a cause argument,
so you can use it to wrap exceptions thrown from inside the
expressions under test.)

Cheers,
Michał


>
>
> On Sun, Jun 9, 2013 at 3:27 AM, Stuart Halloway 
> wrote:
>>
>> Hi Steven,
>>
>> A few thoughts:
>>
>> 1. You may want to look at
>> https://github.com/clojure/test.generative/blob/master/data-model.org.
>>
>> 2. I don't think you want a ref for *assertion-results* -- I am not aware
>> of any use cases that would need transactions. In any case the choice of
>> reference type probably belongs in the impl, not the spec.
>>
>> Good luck with this!
>> Stu
>>
>>
>> On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis 
>> wrote:
>>>
>>> Test2 is a new testing lib for Clojure, where the power is its
>>> simplicity, extensibility, and a SPEC much like Ring's.
>>>
>>> Github: https://github.com/evanescence/test2
>>>
>>> Some background: It came out of discussions with the smart folks in
>>> #clojure, who were frustrated with the inflexibility of existing libs, and
>>> intended this to be the spiritual successor to clojure.test. We wanted
>>> something that was still simple like clojure.test, but could be extended
>>> externally much more easily in case you wanted features found in
>>> clojure.test, Midje, Speclj, or Expectations, or whatever else.
>>>
>>> This is a pre-ANN because it's more of a call for extensions. I've
>>> written one last night, test2-autorunner, which took about an hour. This
>>> should give some idea of how easy it is and how well-designed the SPEC was
>>> by the smart folks of #clojure. There are some ideas at the bottom of the
>>> wiki, but of course any extensions are encouraged.
>>>
>>> -Steven
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>>>
>>>
>>
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>
>
> --
> --
> 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/groups/opt_out.
>
>

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Ah, you're right. Thanks for helping me understand.

Now, the runner and discoverer logic are separated.

Here's the function that calls the runner, passing in a finder:
https://github.com/evanescence/test2/blob/master/src/test2/run.clj
Here's the default runner, and how it uses the finder:
https://github.com/evanescence/test2/blob/master/src/test2/default/runner.clj


On Tue, Jun 11, 2013 at 5:12 PM, Michał Marczyk wrote:

> On 11 June 2013 14:42, Steven Degutis  wrote:
> > Timothy, Brandon, Cedric, et al.:
> >
> > Separating out the Discoverer from the Runner in the SPEC is a bad idea.
> >
> > The main benefit mentioned so far for such a separation is so we can have
> > different definitions of what constitutes a test. For example,
> > test.generative can generate multiple tests from just one block of code.
>
> At least in this thread, the key benefit -- IMO -- was mentioned by
> Brandon (a few e-mails upthread from the one I'm replying to):
>
> On 11 June 2013 01:53, Brandon Bloom  wrote:
> > I
> > might want to just ask "What tests do I have?" without actually running
> > anyway. I may also want a different Executor, like a distributed/parallel
> > executor, while preserving the discovery logic.
>
> So, even if the discovery logic was completely fixed by the spec,
> there's still value in having it separated from the runner.
>
> (For example with clojure.test it's trivial to discover what tests are
> available without running any -- (->> 'test.ns ns-interns vals (filter
> (comp :test meta))). I imagine it'll probably be the case with any
> other framework, but if this effort is specifically about decoupling,
> why have every separate runner reimplement the same discovery logic?)
>
> Cheers,
> Michał
>
>
> >
> > But this creates the same incompatibility problem that we already have
> > between existing test suites. Instead, if we have a single definition of
> a
> > test, every definer is compatible with another.
> >
> > And the current definition is already flexible enough to let you generate
> > multiple tests based on one block of code, like test.generative does.
> >
> >
> > On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey 
> wrote:
> >>
> >> You pass not the Discoverer's results to the Runner, but the Discoverer
> >> itself, which the Runner then invokes at need, possibly more than once.
> >>
> >>
> >> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis 
> >> wrote:
> >>>
> >>> Originally we had Runner split into Discoverer and Runner, but I had to
> >>> combine them both in Runner again so that we can have an autorunner.
> >>>
> >>> Imagine that you've started your autorunner at the command line, and
> you
> >>> create a new test in your existing file and save it. The discoverer has
> >>> already done his role and found all existing tests and passed them to
> the
> >>> runner, so the runner can't see your new test, he only re-runs the
> tests
> >>> that existed when he first started.
> >>>
> >>> That's why I combined them again. So that he could re-discover all the
> >>> tests "matching some criteria" and run them.
> >>>
> >>> So how do you solve this problem while separating Discoverer from
> Runner?
> >>>
> >>>
> >>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom
> >>>  wrote:
> 
>  There are currently 4 roles defined: Definer, Asserter, Runner, and
>  Reporter.
> 
>  It looks like the "Runner" does finding, filtering, and execution. I
>  think you could further break the Runner down into Discoverer and
> Executor.
>  I might want to just ask "What tests do I have?" without actually
> running
>  anyway. I may also want a different Executor, like a
> distributed/parallel
>  executor, while preserving the discovery logic.
> 
>  On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
> >
> > Test2 is a new testing lib for Clojure, where the power is its
> > simplicity, extensibility, and a SPEC much like Ring's.
> >
> > Github: https://github.com/evanescence/test2
> >
> > Some background: It came out of discussions with the smart folks in
> > #clojure, who were frustrated with the inflexibility of existing
> libs, and
> > intended this to be the spiritual successor to clojure.test. We
> wanted
> > something that was still simple like clojure.test, but could be
> extended
> > externally much more easily in case you wanted features found in
> > clojure.test, Midje, Speclj, or Expectations, or whatever else.
> >
> > This is a pre-ANN because it's more of a call for extensions. I've
> > written one last night, test2-autorunner, which took about an hour.
> This
> > should give some idea of how easy it is and how well-designed the
> SPEC was
> > by the smart folks of #clojure. There are some ideas at the bottom
> of the
> > wiki, but of course any extensions are encouraged.
> >
> > -Steven
> 
>  --
>  --
>  You received this message because you are subscribed to 

Re: [pre-ANN] test2, the last Clojure testing framework

[Michał Marczyk]

On 11 June 2013 14:42, Steven Degutis  wrote:
> Timothy, Brandon, Cedric, et al.:
>
> Separating out the Discoverer from the Runner in the SPEC is a bad idea.
>
> The main benefit mentioned so far for such a separation is so we can have
> different definitions of what constitutes a test. For example,
> test.generative can generate multiple tests from just one block of code.

At least in this thread, the key benefit -- IMO -- was mentioned by
Brandon (a few e-mails upthread from the one I'm replying to):

On 11 June 2013 01:53, Brandon Bloom  wrote:
> I
> might want to just ask "What tests do I have?" without actually running
> anyway. I may also want a different Executor, like a distributed/parallel
> executor, while preserving the discovery logic.

So, even if the discovery logic was completely fixed by the spec,
there's still value in having it separated from the runner.

(For example with clojure.test it's trivial to discover what tests are
available without running any -- (->> 'test.ns ns-interns vals (filter
(comp :test meta))). I imagine it'll probably be the case with any
other framework, but if this effort is specifically about decoupling,
why have every separate runner reimplement the same discovery logic?)

Cheers,
Michał


>
> But this creates the same incompatibility problem that we already have
> between existing test suites. Instead, if we have a single definition of a
> test, every definer is compatible with another.
>
> And the current definition is already flexible enough to let you generate
> multiple tests based on one block of code, like test.generative does.
>
>
> On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey  wrote:
>>
>> You pass not the Discoverer's results to the Runner, but the Discoverer
>> itself, which the Runner then invokes at need, possibly more than once.
>>
>>
>> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis 
>> wrote:
>>>
>>> Originally we had Runner split into Discoverer and Runner, but I had to
>>> combine them both in Runner again so that we can have an autorunner.
>>>
>>> Imagine that you've started your autorunner at the command line, and you
>>> create a new test in your existing file and save it. The discoverer has
>>> already done his role and found all existing tests and passed them to the
>>> runner, so the runner can't see your new test, he only re-runs the tests
>>> that existed when he first started.
>>>
>>> That's why I combined them again. So that he could re-discover all the
>>> tests "matching some criteria" and run them.
>>>
>>> So how do you solve this problem while separating Discoverer from Runner?
>>>
>>>
>>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom
>>>  wrote:

 There are currently 4 roles defined: Definer, Asserter, Runner, and
 Reporter.

 It looks like the "Runner" does finding, filtering, and execution. I
 think you could further break the Runner down into Discoverer and Executor.
 I might want to just ask "What tests do I have?" without actually running
 anyway. I may also want a different Executor, like a distributed/parallel
 executor, while preserving the discovery logic.

 On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>
> Test2 is a new testing lib for Clojure, where the power is its
> simplicity, extensibility, and a SPEC much like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of discussions with the smart folks in
> #clojure, who were frustrated with the inflexibility of existing libs, and
> intended this to be the spiritual successor to clojure.test. We wanted
> something that was still simple like clojure.test, but could be extended
> externally much more easily in case you wanted features found in
> clojure.test, Midje, Speclj, or Expectations, or whatever else.
>
> This is a pre-ANN because it's more of a call for extensions. I've
> written one last night, test2-autorunner, which took about an hour. This
> should give some idea of how easy it is and how well-designed the SPEC was
> by the smart folks of #clojure. There are some ideas at the bottom of the
> wiki, but of course any extensions are encouraged.
>
> -Steven

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Thanks for that link Stu. It's quite a lot to take in but it's very useful.

As for *assertion-results*, it seems this has to be in the implementation,
because both Asserters and Runners need a concrete but detached way to
communicate.

Right now they both point to
test2.api.asserters/*assertion-results*.
But I'd really like to get rid of the concreteness of this if possible. But
even throwing exceptions to indicate assertion results won't do, because
the specific exception class to throw/catch is still too concrete.

Anyone have any ideas?


On Sun, Jun 9, 2013 at 3:27 AM, Stuart Halloway
wrote:

> Hi Steven,
>
> A few thoughts:
>
> 1. You may want to look at
> https://github.com/clojure/test.generative/blob/master/data-model.org.
>
> 2. I don't think you want a ref for *assertion-results* -- I am not aware
> of any use cases that would need transactions. In any case the choice of
> reference type probably belongs in the impl, not the spec.
>
> Good luck with this!
> Stu
>
>
> On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis wrote:
>
>> Test2 is a new testing lib for Clojure, where the power is its
>> simplicity, extensibility, and a 
>> SPEC much
>> like Ring's.
>>
>> Github: https://github.com/evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with
>> the smart folks in #clojure, who were frustrated with the inflexibility of
>> existing libs, and intended this to be the spiritual successor to
>> clojure.test. We wanted something that was still simple like clojure.test,
>> but could be extended externally much more easily in case you wanted
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've
>> written one last night, 
>> test2-autorunner,
>> which took about an hour. This should give some idea of how easy it is and
>> how well-designed the SPEC was by the smart folks of #clojure. There are
>> some ideas at the bottom of the wiki, but of course any extensions are
>> encouraged.
>>
>> -Steven
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

As of this moment, it's usable for writing test suites.

The readme is a lot cleaner now: https://github.com/evanescence/test2
The spec is a lot shoerter now:
https://github.com/evanescence/test2/blob/master/SPEC.md
There's a working auto-runner extension:
https://github.com/evanescence/test2-autorunner

You can write tests one of the 3 ways shown in the wiki.
You can use (test2.expect/expect) or (test2.mimic.clojure-test/is) for
making assertions.

Next is to work on making the default reporter better.


On Tue, Jun 11, 2013 at 3:18 PM, Brandon Bloom wrote:

> > Maybe it makes sense to separate out the 'common testing interop' effort
> > from the 'another test framework' effort, so it can can get off the
> ground?
>
> I agree with this. It's easier to solve fewer problems at once. Maybe
> you should reduce the scope to just the common result reporting
> schema? At least for the first try at this.
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Sean Corfield]

That was what I was suggesting the other day... I see more value in
providing a standardizing test result format and better reporting
tools / integration with IDEs etc than in YATF (Yet Another testing
Framework).

On Tue, Jun 11, 2013 at 1:18 PM, Brandon Bloom
 wrote:
>> Maybe it makes sense to separate out the 'common testing interop' effort
>> from the 'another test framework' effort, so it can can get off the ground?
>
> I agree with this. It's easier to solve fewer problems at once. Maybe
> you should reduce the scope to just the common result reporting
> schema? At least for the first try at this.
>
> --
> --
> 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/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Brandon Bloom]

> Maybe it makes sense to separate out the 'common testing interop' effort
> from the 'another test framework' effort, so it can can get off the ground?

I agree with this. It's easier to solve fewer problems at once. Maybe
you should reduce the scope to just the common result reporting
schema? At least for the first try at this.

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Good idea. Thanks guys, I'll do that.


On Tue, Jun 11, 2013 at 3:18 PM, Brandon Bloom wrote:

> > Maybe it makes sense to separate out the 'common testing interop' effort
> > from the 'another test framework' effort, so it can can get off the
> ground?
>
> I agree with this. It's easier to solve fewer problems at once. Maybe
> you should reduce the scope to just the common result reporting
> schema? At least for the first try at this.
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Gary Trakhman]

2 cents, I don't see the value in mixing and matching lower-level
constructs between test frameworks, which also sounds hard.  I see a lot of
value in what the SPEC provides, standardized test-reporting, metadata and
runner infra. This makes tooling's life easier, and would ease the burden
of using multiple test frameworks in a single project.

Maybe it makes sense to separate out the 'common testing interop' effort
from the 'another test framework' effort, so it can can get off the ground?


On Tue, Jun 11, 2013 at 4:09 PM, Steven Degutis  wrote:

> One of the goals is to create extensions that mimic each existing
> test-lib, so that migrating to test2 just means changing your :requires.
>
> But there are some tricky spots:
>
> 1. I don't fully understand how clojure.test's fixtures plays into its
> ability to call test functions from within other test functions.
>
> This probably just requires lots of experimenting and taking extensive
> notes. Tedious but possible.
>
>
> 2. clojure.test's once-fixtures can't be done with the current incarnation
> of the SPEC.
>
> We may be able to add a simple special-case to the Runner and Test-fn
> portion of the spec to make it work.
>
> I'm just worried about being too biased toward clojure.test in this, and
> hard-coding something into the spec that no other extension will ever
> need/want.
>
>
> 3. Midje has the ability to use the infix => anywhere any number of times
> within (fact), which means we can't implement (fact) as a simple
> macro/function.
>
> We can probably just do whatever Midje itself does to make this work.
>
>
> 4. Both Expectations and Midje allow making assertions at the top-level,
> but the spec only lets them exist within a test-fn's execution.
>
> A possible solution is to make (expect) and (fact) have two roles: the
> assertion, as well as conditionally def'ing vars if they aren't already
> inside one.
>
> Another solution is to change the spec to allow making assertions anywhere
> at any time. Several people expressed concerns about the undue complexity
> this would add, and I agree.
>
>
>
> On Sat, Jun 8, 2013 at 10:14 AM, Steven Degutis wrote:
>
>> Test2 is a new testing lib for Clojure, where the power is its
>> simplicity, extensibility, and a 
>> SPEC much
>> like Ring's.
>>
>> Github: https://github.com/evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with
>> the smart folks in #clojure, who were frustrated with the inflexibility of
>> existing libs, and intended this to be the spiritual successor to
>> clojure.test. We wanted something that was still simple like clojure.test,
>> but could be extended externally much more easily in case you wanted
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've
>> written one last night, 
>> test2-autorunner,
>> which took about an hour. This should give some idea of how easy it is and
>> how well-designed the SPEC was by the smart folks of #clojure. There are
>> some ideas at the bottom of the wiki, but of course any extensions are
>> encouraged.
>>
>> -Steven
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

One of the goals is to create extensions that mimic each existing test-lib,
so that migrating to test2 just means changing your :requires.

But there are some tricky spots:

1. I don't fully understand how clojure.test's fixtures plays into its
ability to call test functions from within other test functions.

This probably just requires lots of experimenting and taking extensive
notes. Tedious but possible.


2. clojure.test's once-fixtures can't be done with the current incarnation
of the SPEC.

We may be able to add a simple special-case to the Runner and Test-fn
portion of the spec to make it work.

I'm just worried about being too biased toward clojure.test in this, and
hard-coding something into the spec that no other extension will ever
need/want.


3. Midje has the ability to use the infix => anywhere any number of times
within (fact), which means we can't implement (fact) as a simple
macro/function.

We can probably just do whatever Midje itself does to make this work.


4. Both Expectations and Midje allow making assertions at the top-level,
but the spec only lets them exist within a test-fn's execution.

A possible solution is to make (expect) and (fact) have two roles: the
assertion, as well as conditionally def'ing vars if they aren't already
inside one.

Another solution is to change the spec to allow making assertions anywhere
at any time. Several people expressed concerns about the undue complexity
this would add, and I agree.



On Sat, Jun 8, 2013 at 10:14 AM, Steven Degutis  wrote:

> Test2 is a new testing lib for Clojure, where the power is its simplicity,
> extensibility, and a 
> SPEC much
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> with
> the smart folks in #clojure, who were frustrated with the inflexibility of
> existing libs, and intended this to be the spiritual successor to
> clojure.test. We wanted something that was still simple like clojure.test,
> but could be extended externally much more easily in case you wanted
> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
> else.
>
> This is a pre-ANN because it's more of a call for extensions. I've written
> one last night, 
> test2-autorunner,
> which took about an hour. This should give some idea of how easy it is and
> how well-designed the SPEC was by the smart folks of #clojure. There are
> some ideas at the bottom of the wiki, but of course any extensions are
> encouraged.
>
> -Steven
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Tj Gabbour]

Interesting; these arguments sound oddly like those surrounding Common 
Lisp's "loop" macro. When reading Midje's docs, I got the weird impression 
Brian was aware of the history of "non-lispy" macros.

Taken straight from 
http://www.gigamonkeys.com/book/loop-for-black-belts.html :

(loop repeat 5 
  for x = 0 then y
  and y = 1 then (+ x y)
  collect y) ==> (1 1 2 3 5)


Note:

   - Keywords
   - Infix
   - Updating-machinery is textually close to declaration
   - Of course, the arrow to describe output, which motivates Midje.


I'm not sure how Midje obscures your debugging?

Personally, I have strong positive opinions of loop and Midje. I believe 
that I can show people Midje tests, and they're very clear. To the extent 
that lack of composition/flexibility becomes a problem, I can incur the 
cost of an occasional rewrite; or if I can foresee the complexity becoming 
a problem, I'll do something else more appropriate. My attraction towards 
Lisp lies in clarity; I can often spend a bit of virtuousness to gain this, 
and not notice the cost.

(Disclaimer: my Clojure use isn't nearly as complex as yours; I don't get 
to use it as much as I'd wish. So maybe I'm missing something.)


All the best,
  Tj

On Tuesday, June 11, 2013 2:27:03 AM UTC+2, tbc++ wrote:
>
> >> It might surprise you to know that there are actual human beings with 
> feelings who write the software you slam.
>
> You are right. And I apologize for my strong words. For the goals that 
> Midje strives for, it is an excellent library. 
>
> My reaction is more against the ideas behind Midje (from the docs): "I 
> believe you should have the same reaction to test suites written like that: 
> a slavish adherence to Lisp style in tests incorrectly exalts purity over 
> user-friendliness. "
>
> I disagree strongly with this assertion. I wish to see my tests in the 
> same language as my code. Midje succeeds in reaching the goals that it sets 
> forth. I can write tests, top-to-bottom, left-to-right. But at the expense 
> of debugging power, and intuitiveness. 
>
> It may be harder to read:
>
> (is (= (foo 1) 42))
>
> But even a beginner programmer in Clojure can parse and understand it. 
>
> I think the ideals Midje enspouses may be more applicable in other 
> languages, and IMO they are not needed in Clojure. 
>
> These are all my own, highly biased, opinions. I congratulate you, Brian, 
> on a well written, mature, library. I simply question the premise. 
>
> Timothy
>
>
> On Mon, Jun 10, 2013 at 5:30 PM, Brian Marick 
> 
> > wrote:
>
>>
>> On Jun 10, 2013, at 9:20 AM, Timothy Baldridge 
>> > 
>> wrote:
>> > Midje on the other hand, is a massive pile of macros and DSLs that so 
>> complicate your code that advanced tests are insanely hard to debug. ... 
>> And I can't tell you how many dozens of hours I've lost trying to figure 
>> out why Midje doesn't like my test results.
>>
>> It might surprise you to know that there are actual human beings with 
>> feelings who write the software you slam.
>>
>> Before people spend dozens of hours being frustrated, I suggest they post 
>> to the Midje mailing list. I try to be reasonably responsive, and I have a 
>> good track record helping people with their problems.
>>
>> 
>> Latest book: /Functional Programming for the Object-Oriented Programmer/
>> https://leanpub.com/fp-oo
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>
> -- 
> “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/groups/opt_o

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

You're right. I'm sorry for doing that. From now on I'll make a bigger
point of it to be more correct.


On Tue, Jun 11, 2013 at 10:18 AM, Jay Fields  wrote:

> On Tuesday, June 11, 2013 11:11:23 AM UTC-4, Steven Degutis wrote:
>
>> Jay,
>>
>> [elided]
>>
> That's the issue I'm trying to solve. Maybe that's not what everyone sees
>> in this. But this is the big win I see in it.
>>
>
> I think that's a good goal, I think you should stick to that, instead of
> continuing to make incorrect statements about the existing libraries.
>
> So far you've called my framework 'inflexible' and claimed that 'around'
> isn't possible. Both statements are (a) incorrect and (b) not relevant. I
> have an issue with that, and will continue to keep responding as long as
> you keep making inaccurate statements.
>
> Cheers, Jay
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

On Tuesday, June 11, 2013 11:11:23 AM UTC-4, Steven Degutis wrote:

> Jay,
>
> [elided] 
>
That's the issue I'm trying to solve. Maybe that's not what everyone sees 
> in this. But this is the big win I see in it.
>

I think that's a good goal, I think you should stick to that, instead of 
continuing to make incorrect statements about the existing libraries. 

So far you've called my framework 'inflexible' and claimed that 'around' 
isn't possible. Both statements are (a) incorrect and (b) not relevant. I 
have an issue with that, and will continue to keep responding as long as 
you keep making inaccurate statements. 

Cheers, Jay

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Jay,

Imagine there is no Micah or Marick or you, there's only Bob and Alice, two
Clojure geeks who have a really big test suite.

If they wrote their whole test suite using clojure.test, they can't use an
autorunner unless they rewrite it in one of the other libs.

If they wrote their whole test suite using expectations, they can't use
difftest unless they rewrite it in clojure.test.

If they wrote their whole test suite using speclj, they can't use your
(expect) function unless they rewrite the whole thing in expectations.

etc.

But these libs share mostly the same feature-set with each other. So why do
they each re-invent the wheel in a way that make them incompatible with one
another?

That's the issue I'm trying to solve. Maybe that's not what everyone sees
in this. But this is the big win I see in it.


On Tue, Jun 11, 2013 at 9:43 AM, Jay Fields  wrote:

> On Tuesday, June 11, 2013 12:39:59 AM UTC-4, Steven Degutis wrote:
>
>> It's pretty frustrating that I, a regular old Clojure user who likes
>> writing tests, can't mix and match tools from existing testing libraries.
>> Seriously, there's 4 major ones (clojure.test, speclj, midje, expectations)
>> and they each do mostly the same things but vary slightly in some areas. I
>> can't use speclj's around-all feature with expectations' (expect) function.
>>
>
> Unless I'm missing something, I don't see how expectations doesn't support
> around.
>
> here's the speclj from the wiki:
> https://gist.github.com/jaycfields/5757320
> here's the expectations equivalent:
> https://gist.github.com/jaycfields/5757387
>
> Maybe the issue is more around knowing the frameworks than lack of
> features - which could speak to a need for better documentation.
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[JeremyS]

I'd like to support Laurent on this and the Test2 effort, having a spec of 
tests in terms of abstractions useable from library to library, possibly 
having tests as data, (since I have learned that it's all about data) would 
really be really useful. The ring-spec like idea for tests really has 
something good to it.

Now, opinion time (more opinionated actually). Midje might be full of 
macros and abstractions that I don't understand when I read the code. Hell 
it's full of them. But I honestly never had to read it to write my tests. 
More It's well documented and I there's is more functionality in the doc 
than I have had to use. So congrats Brian.

Once again it would also be nice to see Test2 include ClojureScript. And 
the spec might be a good start.

Cheers,

Jeremys.

On Tuesday, June 11, 2013 2:56:44 PM UTC+2, Laurent PETIT wrote:
>
> You know, if some day all the test libs / frameworks can be run, test 
> results exploited, etc. through the same abstraction, this will 
> greatly ease the pain of tools developers ! 
>
> I would better write once the integration between Eclipse way of 
> running and displaying tests, than once per library ! 
>
> So ... looking forward to see this globally adopted :-) 
>
> 2013/6/11 Steven Degutis >: 
> > Timothy, Brandon, Cedric, et al.: 
> > 
> > Separating out the Discoverer from the Runner in the SPEC is a bad idea. 
> > 
> > The main benefit mentioned so far for such a separation is so we can 
> have 
> > different definitions of what constitutes a test. For example, 
> > test.generative can generate multiple tests from just one block of code. 
> > 
> > But this creates the same incompatibility problem that we already have 
> > between existing test suites. Instead, if we have a single definition of 
> a 
> > test, every definer is compatible with another. 
> > 
> > And the current definition is already flexible enough to let you 
> generate 
> > multiple tests based on one block of code, like test.generative does. 
> > 
> > 
> > On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey 
> > > 
> wrote: 
> >> 
> >> You pass not the Discoverer's results to the Runner, but the Discoverer 
> >> itself, which the Runner then invokes at need, possibly more than once. 
> >> 
> >> 
> >> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis 
> >> > 
>
> >> wrote: 
> >>> 
> >>> Originally we had Runner split into Discoverer and Runner, but I had 
> to 
> >>> combine them both in Runner again so that we can have an autorunner. 
> >>> 
> >>> Imagine that you've started your autorunner at the command line, and 
> you 
> >>> create a new test in your existing file and save it. The discoverer 
> has 
> >>> already done his role and found all existing tests and passed them to 
> the 
> >>> runner, so the runner can't see your new test, he only re-runs the 
> tests 
> >>> that existed when he first started. 
> >>> 
> >>> That's why I combined them again. So that he could re-discover all the 
> >>> tests "matching some criteria" and run them. 
> >>> 
> >>> So how do you solve this problem while separating Discoverer from 
> Runner? 
> >>> 
> >>> 
> >>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom 
> >>> > wrote: 
>  
>  There are currently 4 roles defined: Definer, Asserter, Runner, and 
>  Reporter. 
>  
>  It looks like the "Runner" does finding, filtering, and execution. I 
>  think you could further break the Runner down into Discoverer and 
> Executor. 
>  I might want to just ask "What tests do I have?" without actually 
> running 
>  anyway. I may also want a different Executor, like a 
> distributed/parallel 
>  executor, while preserving the discovery logic. 
>  
>  On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote: 
> > 
> > Test2 is a new testing lib for Clojure, where the power is its 
> > simplicity, extensibility, and a SPEC much like Ring's. 
> > 
> > Github: https://github.com/evanescence/test2 
> > 
> > Some background: It came out of discussions with the smart folks in 
> > #clojure, who were frustrated with the inflexibility of existing 
> libs, and 
> > intended this to be the spiritual successor to clojure.test. We 
> wanted 
> > something that was still simple like clojure.test, but could be 
> extended 
> > externally much more easily in case you wanted features found in 
> > clojure.test, Midje, Speclj, or Expectations, or whatever else. 
> > 
> > This is a pre-ANN because it's more of a call for extensions. I've 
> > written one last night, test2-autorunner, which took about an hour. 
> This 
> > should give some idea of how easy it is and how well-designed the 
> SPEC was 
> > by the smart folks of #clojure. There are some ideas at the bottom 
> of the 
> > wiki, but of course any extensions are encouraged. 
> > 
> > -Steven 
>  
>  -- 
>  -- 
>  You received this message because you are subscribed to the Google 

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

On Tuesday, June 11, 2013 12:39:59 AM UTC-4, Steven Degutis wrote:

> It's pretty frustrating that I, a regular old Clojure user who likes 
> writing tests, can't mix and match tools from existing testing libraries. 
> Seriously, there's 4 major ones (clojure.test, speclj, midje, expectations) 
> and they each do mostly the same things but vary slightly in some areas. I 
> can't use speclj's around-all feature with expectations' (expect) function.
>

Unless I'm missing something, I don't see how expectations doesn't support 
around.

here's the speclj from the wiki: https://gist.github.com/jaycfields/5757320
here's the expectations equivalent: 
https://gist.github.com/jaycfields/5757387 

Maybe the issue is more around knowing the frameworks than lack of features 
- which could speak to a need for better documentation.

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Laurent PETIT]

You know, if some day all the test libs / frameworks can be run, test
results exploited, etc. through the same abstraction, this will
greatly ease the pain of tools developers !

I would better write once the integration between Eclipse way of
running and displaying tests, than once per library !

So ... looking forward to see this globally adopted :-)

2013/6/11 Steven Degutis :
> Timothy, Brandon, Cedric, et al.:
>
> Separating out the Discoverer from the Runner in the SPEC is a bad idea.
>
> The main benefit mentioned so far for such a separation is so we can have
> different definitions of what constitutes a test. For example,
> test.generative can generate multiple tests from just one block of code.
>
> But this creates the same incompatibility problem that we already have
> between existing test suites. Instead, if we have a single definition of a
> test, every definer is compatible with another.
>
> And the current definition is already flexible enough to let you generate
> multiple tests based on one block of code, like test.generative does.
>
>
> On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey  wrote:
>>
>> You pass not the Discoverer's results to the Runner, but the Discoverer
>> itself, which the Runner then invokes at need, possibly more than once.
>>
>>
>> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis 
>> wrote:
>>>
>>> Originally we had Runner split into Discoverer and Runner, but I had to
>>> combine them both in Runner again so that we can have an autorunner.
>>>
>>> Imagine that you've started your autorunner at the command line, and you
>>> create a new test in your existing file and save it. The discoverer has
>>> already done his role and found all existing tests and passed them to the
>>> runner, so the runner can't see your new test, he only re-runs the tests
>>> that existed when he first started.
>>>
>>> That's why I combined them again. So that he could re-discover all the
>>> tests "matching some criteria" and run them.
>>>
>>> So how do you solve this problem while separating Discoverer from Runner?
>>>
>>>
>>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom
>>>  wrote:

 There are currently 4 roles defined: Definer, Asserter, Runner, and
 Reporter.

 It looks like the "Runner" does finding, filtering, and execution. I
 think you could further break the Runner down into Discoverer and Executor.
 I might want to just ask "What tests do I have?" without actually running
 anyway. I may also want a different Executor, like a distributed/parallel
 executor, while preserving the discovery logic.

 On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>
> Test2 is a new testing lib for Clojure, where the power is its
> simplicity, extensibility, and a SPEC much like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of discussions with the smart folks in
> #clojure, who were frustrated with the inflexibility of existing libs, and
> intended this to be the spiritual successor to clojure.test. We wanted
> something that was still simple like clojure.test, but could be extended
> externally much more easily in case you wanted features found in
> clojure.test, Midje, Speclj, or Expectations, or whatever else.
>
> This is a pre-ANN because it's more of a call for extensions. I've
> written one last night, test2-autorunner, which took about an hour. This
> should give some idea of how easy it is and how well-designed the SPEC was
> by the smart folks of #clojure. There are some ideas at the bottom of the
> wiki, but of course any extensions are encouraged.
>
> -Steven

 --
 --
 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/groups/opt_out.


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

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Timothy, Brandon, Cedric, et al.:

Separating out the Discoverer from the Runner in the SPEC is a bad idea.

The main benefit mentioned so far for such a separation is so we can have
different definitions of what constitutes a test. For example,
test.generative can generate multiple tests from just one block of code.

But this creates the same incompatibility problem that we already have
between existing test suites. Instead, if we have a single definition of a
test, every definer is compatible with another.

And the current definition is already flexible enough to let you generate
multiple tests based on one block of code, like test.generative does.


On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey  wrote:

> You pass not the Discoverer's results to the Runner, but the Discoverer
> itself, which the Runner then invokes at need, possibly more than once.
>
>
> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis wrote:
>
>> Originally we had Runner split into Discoverer and Runner, but I had to
>> combine them both in Runner again so that we can have an autorunner.
>>
>> Imagine that you've started your autorunner at the command line, and you
>> create a new test in your existing file and save it. The discoverer has
>> already done his role and found all existing tests and passed them to the
>> runner, so the runner can't see your new test, he only re-runs the tests
>> that existed when he first started.
>>
>> That's why I combined them again. So that he could re-discover all the
>> tests "matching some criteria" and run them.
>>
>> So how do you solve this problem while separating Discoverer from Runner?
>>
>>
>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom > > wrote:
>>
>>> There are currently 4 roles defined: Definer, Asserter, Runner, and
>>> Reporter.
>>>
>>> It looks like the "Runner" does finding, filtering, and execution. I
>>> think you could further break the Runner down into Discoverer and Executor.
>>> I might want to just ask "What tests do I have?" without actually running
>>> anyway. I may also want a different Executor, like a distributed/parallel
>>> executor, while preserving the discovery logic.
>>>
>>> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>>>
 Test2 is a new testing lib for Clojure, where the power is its
 simplicity, extensibility, and a 
 SPEC much
 like Ring's.

 Github: 
 https://github.com/**evanescence/test2

 Some background: It came out of 
 discussions
  with
 the smart folks in #clojure, who were frustrated with the inflexibility of
 existing libs, and intended this to be the spiritual successor to
 clojure.test. We wanted something that was still simple like clojure.test,
 but could be extended externally much more easily in case you wanted
 features found in clojure.test, Midje, Speclj, or Expectations, or whatever
 else.

 This is a pre-ANN because it's more of a call for extensions. I've
 written one last night, 
 test2-autorunner,
 which took about an hour. This should give some idea of how easy it is and
 how well-designed the SPEC was by the smart folks of #clojure. There are
 some ideas at the bottom of the wiki, but of course any extensions are
 encouraged.

 -Steven

>>>  --
>>> --
>>> 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/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> 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: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Beautiful!


On Tue, Jun 11, 2013 at 1:57 AM, Cedric Greevey  wrote:

> You pass not the Discoverer's results to the Runner, but the Discoverer
> itself, which the Runner then invokes at need, possibly more than once.
>
>
> On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis wrote:
>
>> Originally we had Runner split into Discoverer and Runner, but I had to
>> combine them both in Runner again so that we can have an autorunner.
>>
>> Imagine that you've started your autorunner at the command line, and you
>> create a new test in your existing file and save it. The discoverer has
>> already done his role and found all existing tests and passed them to the
>> runner, so the runner can't see your new test, he only re-runs the tests
>> that existed when he first started.
>>
>> That's why I combined them again. So that he could re-discover all the
>> tests "matching some criteria" and run them.
>>
>> So how do you solve this problem while separating Discoverer from Runner?
>>
>>
>> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom > > wrote:
>>
>>> There are currently 4 roles defined: Definer, Asserter, Runner, and
>>> Reporter.
>>>
>>> It looks like the "Runner" does finding, filtering, and execution. I
>>> think you could further break the Runner down into Discoverer and Executor.
>>> I might want to just ask "What tests do I have?" without actually running
>>> anyway. I may also want a different Executor, like a distributed/parallel
>>> executor, while preserving the discovery logic.
>>>
>>> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>>>
 Test2 is a new testing lib for Clojure, where the power is its
 simplicity, extensibility, and a 
 SPEC much
 like Ring's.

 Github: 
 https://github.com/**evanescence/test2

 Some background: It came out of 
 discussions
  with
 the smart folks in #clojure, who were frustrated with the inflexibility of
 existing libs, and intended this to be the spiritual successor to
 clojure.test. We wanted something that was still simple like clojure.test,
 but could be extended externally much more easily in case you wanted
 features found in clojure.test, Midje, Speclj, or Expectations, or whatever
 else.

 This is a pre-ANN because it's more of a call for extensions. I've
 written one last night, 
 test2-autorunner,
 which took about an hour. This should give some idea of how easy it is and
 how well-designed the SPEC was by the smart folks of #clojure. There are
 some ideas at the bottom of the wiki, but of course any extensions are
 encouraged.

 -Steven

>>>  --
>>> --
>>> 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/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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 email

Re: [pre-ANN] test2, the last Clojure testing framework

[Cedric Greevey]

You pass not the Discoverer's results to the Runner, but the Discoverer
itself, which the Runner then invokes at need, possibly more than once.


On Tue, Jun 11, 2013 at 1:35 AM, Steven Degutis  wrote:

> Originally we had Runner split into Discoverer and Runner, but I had to
> combine them both in Runner again so that we can have an autorunner.
>
> Imagine that you've started your autorunner at the command line, and you
> create a new test in your existing file and save it. The discoverer has
> already done his role and found all existing tests and passed them to the
> runner, so the runner can't see your new test, he only re-runs the tests
> that existed when he first started.
>
> That's why I combined them again. So that he could re-discover all the
> tests "matching some criteria" and run them.
>
> So how do you solve this problem while separating Discoverer from Runner?
>
>
> On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom 
> wrote:
>
>> There are currently 4 roles defined: Definer, Asserter, Runner, and
>> Reporter.
>>
>> It looks like the "Runner" does finding, filtering, and execution. I
>> think you could further break the Runner down into Discoverer and Executor.
>> I might want to just ask "What tests do I have?" without actually running
>> anyway. I may also want a different Executor, like a distributed/parallel
>> executor, while preserving the discovery logic.
>>
>> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>>
>>> Test2 is a new testing lib for Clojure, where the power is its
>>> simplicity, extensibility, and a 
>>> SPEC much
>>> like Ring's.
>>>
>>> Github: 
>>> https://github.com/**evanescence/test2
>>>
>>> Some background: It came out of 
>>> discussions
>>>  with
>>> the smart folks in #clojure, who were frustrated with the inflexibility of
>>> existing libs, and intended this to be the spiritual successor to
>>> clojure.test. We wanted something that was still simple like clojure.test,
>>> but could be extended externally much more easily in case you wanted
>>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>>> else.
>>>
>>> This is a pre-ANN because it's more of a call for extensions. I've
>>> written one last night, 
>>> test2-autorunner,
>>> which took about an hour. This should give some idea of how easy it is and
>>> how well-designed the SPEC was by the smart folks of #clojure. There are
>>> some ideas at the bottom of the wiki, but of course any extensions are
>>> encouraged.
>>>
>>> -Steven
>>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Originally we had Runner split into Discoverer and Runner, but I had to
combine them both in Runner again so that we can have an autorunner.

Imagine that you've started your autorunner at the command line, and you
create a new test in your existing file and save it. The discoverer has
already done his role and found all existing tests and passed them to the
runner, so the runner can't see your new test, he only re-runs the tests
that existed when he first started.

That's why I combined them again. So that he could re-discover all the
tests "matching some criteria" and run them.

So how do you solve this problem while separating Discoverer from Runner?


On Mon, Jun 10, 2013 at 6:53 PM, Brandon Bloom wrote:

> There are currently 4 roles defined: Definer, Asserter, Runner, and
> Reporter.
>
> It looks like the "Runner" does finding, filtering, and execution. I think
> you could further break the Runner down into Discoverer and Executor. I
> might want to just ask "What tests do I have?" without actually running
> anyway. I may also want a different Executor, like a distributed/parallel
> executor, while preserving the discovery logic.
>
> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>
>> Test2 is a new testing lib for Clojure, where the power is its
>> simplicity, extensibility, and a 
>> SPEC much
>> like Ring's.
>>
>> Github: 
>> https://github.com/**evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with
>> the smart folks in #clojure, who were frustrated with the inflexibility of
>> existing libs, and intended this to be the spiritual successor to
>> clojure.test. We wanted something that was still simple like clojure.test,
>> but could be extended externally much more easily in case you wanted
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've
>> written one last night, 
>> test2-autorunner,
>> which took about an hour. This should give some idea of how easy it is and
>> how well-designed the SPEC was by the smart folks of #clojure. There are
>> some ideas at the bottom of the wiki, but of course any extensions are
>> encouraged.
>>
>> -Steven
>>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

It's pretty frustrating that I, a regular old Clojure user who likes
writing tests, can't mix and match tools from existing testing libraries.
Seriously, there's 4 major ones (clojure.test, speclj, midje, expectations)
and they each do mostly the same things but vary slightly in some areas. I
can't use speclj's around-all feature with expectations' (expect) function,
or midje's auto-runner with clojure.test's (is) assertions. Or
lein-difftest with midje, expectations, or speclj.

So let's fix that.


On Sun, Jun 9, 2013 at 11:45 AM, Jay Fields  wrote:

> I'd like to mention that expectations* has 0 open pull requests, 0 open
> issues, and is very actively maintained**. Steven, I don't want to
> discourage you from creating your own testing framework, I think everyone
> should, it's a very educational experience.
>
> I just wanted to be clear that no one has ever asked me for any help
> extending expectations, and anyone who chooses to use expectations should
> feel free to contact me with any suggestions.
>
> * https://github.com/jaycfields/expectations
> ** https://github.com/jaycfields/expectations/commits/master
>
>
> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>>
>> Test2 is a new testing lib for Clojure, where the power is its
>> simplicity, extensibility, and a 
>> SPEC much
>> like Ring's.
>>
>> Github: 
>> https://github.com/**evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with
>> the smart folks in #clojure, who were frustrated with the inflexibility of
>> existing libs, and intended this to be the spiritual successor to
>> clojure.test. We wanted something that was still simple like clojure.test,
>> but could be extended externally much more easily in case you wanted
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've
>> written one last night, 
>> test2-autorunner,
>> which took about an hour. This should give some idea of how easy it is and
>> how well-designed the SPEC was by the smart folks of #clojure. There are
>> some ideas at the bottom of the wiki, but of course any extensions are
>> encouraged.
>>
>> -Steven
>>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Timothy Baldridge]

>> It might surprise you to know that there are actual human beings with
feelings who write the software you slam.

You are right. And I apologize for my strong words. For the goals that
Midje strives for, it is an excellent library.

My reaction is more against the ideas behind Midje (from the docs): "I
believe you should have the same reaction to test suites written like that:
a slavish adherence to Lisp style in tests incorrectly exalts purity over
user-friendliness. "

I disagree strongly with this assertion. I wish to see my tests in the same
language as my code. Midje succeeds in reaching the goals that it sets
forth. I can write tests, top-to-bottom, left-to-right. But at the expense
of debugging power, and intuitiveness.

It may be harder to read:

(is (= (foo 1) 42))

But even a beginner programmer in Clojure can parse and understand it.

I think the ideals Midje enspouses may be more applicable in other
languages, and IMO they are not needed in Clojure.

These are all my own, highly biased, opinions. I congratulate you, Brian,
on a well written, mature, library. I simply question the premise.

Timothy


On Mon, Jun 10, 2013 at 5:30 PM, Brian Marick  wrote:

>
> On Jun 10, 2013, at 9:20 AM, Timothy Baldridge 
> wrote:
> > Midje on the other hand, is a massive pile of macros and DSLs that so
> complicate your code that advanced tests are insanely hard to debug. ...
> And I can't tell you how many dozens of hours I've lost trying to figure
> out why Midje doesn't like my test results.
>
> It might surprise you to know that there are actual human beings with
> feelings who write the software you slam.
>
> Before people spend dozens of hours being frustrated, I suggest they post
> to the Midje mailing list. I try to be reasonably responsive, and I have a
> good track record helping people with their problems.
>
> 
> Latest book: /Functional Programming for the Object-Oriented Programmer/
> https://leanpub.com/fp-oo
>
> --
> --
> 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/groups/opt_out.
>
>
>


-- 
“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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Brandon Bloom]

There are currently 4 roles defined: Definer, Asserter, Runner, and 
Reporter.

It looks like the "Runner" does finding, filtering, and execution. I think 
you could further break the Runner down into Discoverer and Executor. I 
might want to just ask "What tests do I have?" without actually running 
anyway. I may also want a different Executor, like a distributed/parallel 
executor, while preserving the discovery logic.

On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>
> Test2 is a new testing lib for Clojure, where the power is its simplicity, 
> extensibility, and a 
> SPEC much 
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> with 
> the smart folks in #clojure, who were frustrated with the inflexibility of 
> existing libs, and intended this to be the spiritual successor to 
> clojure.test. We wanted something that was still simple like clojure.test, 
> but could be extended externally much more easily in case you wanted 
> features found in clojure.test, Midje, Speclj, or Expectations, or whatever 
> else.
>
> This is a pre-ANN because it's more of a call for extensions. I've written 
> one last night, 
> test2-autorunner, 
> which took about an hour. This should give some idea of how easy it is and 
> how well-designed the SPEC was by the smart folks of #clojure. There are 
> some ideas at the bottom of the wiki, but of course any extensions are 
> encouraged.
>
> -Steven
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Brian Marick]

On Jun 10, 2013, at 9:20 AM, Timothy Baldridge  wrote:
> Midje on the other hand, is a massive pile of macros and DSLs that so 
> complicate your code that advanced tests are insanely hard to debug. ... And 
> I can't tell you how many dozens of hours I've lost trying to figure out why 
> Midje doesn't like my test results. 

It might surprise you to know that there are actual human beings with feelings 
who write the software you slam. 

Before people spend dozens of hours being frustrated, I suggest they post to 
the Midje mailing list. I try to be reasonably responsive, and I have a good 
track record helping people with their problems.


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

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[JeremyS]

Hi guys,
>
>
This might not be a good idea but if the goal is to have a minimal testing 
utilities (or testing abstractions might I say ?) do you plan
to port them to ClojureScript ? The idea of a minimal testing utility that 
would be extensible to suit everyone's taste and style of testing would be 
nice. But right now I don't think we have as many nice options in 
ClojureScript as we have in Clojure. 

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Timothy Baldridge]

>> You can certainly use with-redefs with any testing library/framework, or
you can pass dependencies into your production-code functions. I think
perhaps I'm missing the detail you're seeing on how using a particular test
framework encourages using global vars - can you elaborate?

You're right, my bad. I just looked at the Speclj docs as it's been some
time since I used the framework. I forgot that "with" defines a new var
that is passed in to the functions. I like that approach. Seems like I saw
a demo once that used with-redefs, but I'm probably hallucinating.

Timothy


On Mon, Jun 10, 2013 at 9:11 AM, Colin Jones  wrote:

>
>
> On Monday, June 10, 2013 9:20:31 AM UTC-5, tbc++ wrote:
>>
>> >> 1) testing recursive functions. I want to test what a recursion STEP
>> does, not the >> whole function. Can I mock 'recur'?
>>
>> You shouldn't need to, pull the body of the loop out as as separate
>> function, then test that function.
>>
>> >> 2) testing sequence, esp. lazy
>>
>> For this, I often create a generator function, or do what I suggested for
>> 1). If your code is functional you should be able to test subsets of a lazy
>> seq by supplying the correct arguments to your generation function.
>>
>> >> 3) IoC typically makes code more testable. What are Clojure
>> alternatives for IoC? Pass all dependencies as parameters to your function?
>>
>> That's exactly what you should do. Functions should be small enough to
>> only need a few dependencies. If they need more, consider putting them into
>> a hash-map.
>>
>> Some systems like Midje or Speclj have systems for helping with this, but
>> I have only  ever been frustrated with them. In the case of Speclj,
>> var-redefs are prefered, which assume that you'll have global vars to hold
>> your state, which is exactly the behavior I try to avoid.
>>
>>
> You can certainly use with-redefs with any testing library/framework, or
> you can pass dependencies into your production-code functions. I think
> perhaps I'm missing the detail you're seeing on how using a particular test
> framework encourages using global vars - can you elaborate?
>
>
>
>
>> Midje on the other hand, is a massive pile of macros and DSLs that
>> so complicate your code that advanced tests are insanely hard to debug. Pop
>> Quiz: Midje's "fact" and "provided", how are those parsed and executed? I
>> don't know! It's a black box, and I'd have to go and read the codebase to
>> understand why they don't work the way I think they should. Because
>> Midje exposes tests in a custom DSL, you can't approach it as if it was
>> Clojure, it's a different language with different semantics.
>>
>> I want my tests to be in the same language as my code, this is why I
>> tend to stick with clojure.test. What are tests? Functions. What are
>> assertions? a simple wrapper around "assert". Simplicity at its finest.
>> Sure, the library is a bit underpowered, but I've never been frustrated with
>> clojure.test. And I can't tell you how many dozens of hours I've lost
>> trying to figure out why Midje doesn't like my test results.
>>
>> Oh, and lein-difftestthat's one awesome bit of code. It provides
>> extra information, and yet doesn't add needless complexity.
>>
>> Timothy
>>
>>
>> On Sun, Jun 9, 2013 at 11:22 PM, julianrz  wrote:
>>
>>> This may be a little off topic, but does this, or any other framework,
>>> solve some testing inconveniences that exist in Clojure and probably other
>>> functional languages:
>>> 1) testing recursive functions. I want to test what a recursion STEP
>>> does, not the whole function. Can I mock 'recur'?
>>> 2) testing sequence, esp. lazy
>>> 3) IoC typically makes code more testable. What are Clojure alternatives
>>> for IoC? Pass all dependencies as parameters to your function?
>>>
>>> I wonder if code=data philosophy of Lisp enables some testing techniques
>>> that are impossible in languages like Java. Typically you can only test a
>>> function programmatically, not arbitrary code block. But you can probably
>>> introspect code very easily in Clojure, and test parts, regardless if they
>>> are functions or not. A test framework could support that in principle...
>>>
>>> I found that functional code is harder to separate, which would make it
>>> harder to test...
>>>
>>> Any thoughts?
>>> Thanks,
>>> Julian
>>>
>>>  --
>>> --
>>> 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 

Re: [pre-ANN] test2, the last Clojure testing framework

[Colin Jones]

On Monday, June 10, 2013 9:20:31 AM UTC-5, tbc++ wrote:
>
> >> 1) testing recursive functions. I want to test what a recursion STEP 
> does, not the >> whole function. Can I mock 'recur'?
>
> You shouldn't need to, pull the body of the loop out as as separate 
> function, then test that function.
>
> >> 2) testing sequence, esp. lazy
>
> For this, I often create a generator function, or do what I suggested for 
> 1). If your code is functional you should be able to test subsets of a lazy 
> seq by supplying the correct arguments to your generation function. 
>
> >> 3) IoC typically makes code more testable. What are Clojure 
> alternatives for IoC? Pass all dependencies as parameters to your function?
>
> That's exactly what you should do. Functions should be small enough to 
> only need a few dependencies. If they need more, consider putting them into 
> a hash-map. 
>
> Some systems like Midje or Speclj have systems for helping with this, but 
> I have only  ever been frustrated with them. In the case of Speclj, 
> var-redefs are prefered, which assume that you'll have global vars to hold 
> your state, which is exactly the behavior I try to avoid. 
>
>
You can certainly use with-redefs with any testing library/framework, or 
you can pass dependencies into your production-code functions. I think 
perhaps I'm missing the detail you're seeing on how using a particular test 
framework encourages using global vars - can you elaborate?


 

> Midje on the other hand, is a massive pile of macros and DSLs that 
> so complicate your code that advanced tests are insanely hard to debug. Pop 
> Quiz: Midje's "fact" and "provided", how are those parsed and executed? I 
> don't know! It's a black box, and I'd have to go and read the codebase to 
> understand why they don't work the way I think they should. Because Midje 
> exposes tests in a custom DSL, you can't approach it as if it was Clojure, 
> it's a different language with different semantics. 
>
> I want my tests to be in the same language as my code, this is why I tend 
> to stick with clojure.test. What are tests? Functions. What are assertions? 
> a simple wrapper around "assert". Simplicity at its finest. Sure, the 
> library is a bit underpowered, but I've never been frustrated with 
> clojure.test. And I can't tell you how many dozens of hours I've lost 
> trying to figure out why Midje doesn't like my test results. 
>
> Oh, and lein-difftestthat's one awesome bit of code. It provides extra 
> information, and yet doesn't add needless complexity. 
>
> Timothy
>
>
> On Sun, Jun 9, 2013 at 11:22 PM, julianrz 
> > wrote:
>
>> This may be a little off topic, but does this, or any other framework, 
>> solve some testing inconveniences that exist in Clojure and probably other 
>> functional languages:
>> 1) testing recursive functions. I want to test what a recursion STEP 
>> does, not the whole function. Can I mock 'recur'?
>> 2) testing sequence, esp. lazy
>> 3) IoC typically makes code more testable. What are Clojure alternatives 
>> for IoC? Pass all dependencies as parameters to your function? 
>>
>> I wonder if code=data philosophy of Lisp enables some testing techniques 
>> that are impossible in languages like Java. Typically you can only test a 
>> function programmatically, not arbitrary code block. But you can probably 
>> introspect code very easily in Clojure, and test parts, regardless if they 
>> are functions or not. A test framework could support that in principle...
>>
>> I found that functional code is harder to separate, which would make it 
>> harder to test... 
>>
>> Any thoughts?
>> Thanks,
>> Julian  
>>
>>  -- 
>> -- 
>> 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/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> “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/cl

Re: [pre-ANN] test2, the last Clojure testing framework

[Timothy Baldridge]

>> 1) testing recursive functions. I want to test what a recursion STEP
does, not the >> whole function. Can I mock 'recur'?

You shouldn't need to, pull the body of the loop out as as separate
function, then test that function.

>> 2) testing sequence, esp. lazy

For this, I often create a generator function, or do what I suggested for
1). If your code is functional you should be able to test subsets of a lazy
seq by supplying the correct arguments to your generation function.

>> 3) IoC typically makes code more testable. What are Clojure alternatives
for IoC? Pass all dependencies as parameters to your function?

That's exactly what you should do. Functions should be small enough to only
need a few dependencies. If they need more, consider putting them into a
hash-map.

Some systems like Midje or Speclj have systems for helping with this, but I
have only  ever been frustrated with them. In the case of Speclj,
var-redefs are prefered, which assume that you'll have global vars to hold
your state, which is exactly the behavior I try to avoid.

Midje on the other hand, is a massive pile of macros and DSLs that
so complicate your code that advanced tests are insanely hard to debug. Pop
Quiz: Midje's "fact" and "provided", how are those parsed and executed? I
don't know! It's a black box, and I'd have to go and read the codebase to
understand why they don't work the way I think they should. Because Midje
exposes tests in a custom DSL, you can't approach it as if it was Clojure,
it's a different language with different semantics.

I want my tests to be in the same language as my code, this is why I tend
to stick with clojure.test. What are tests? Functions. What are assertions?
a simple wrapper around "assert". Simplicity at its finest. Sure, the
library is a bit underpowered, but I've never been frustrated with
clojure.test. And I can't tell you how many dozens of hours I've lost
trying to figure out why Midje doesn't like my test results.

Oh, and lein-difftestthat's one awesome bit of code. It provides extra
information, and yet doesn't add needless complexity.

Timothy


On Sun, Jun 9, 2013 at 11:22 PM, julianrz  wrote:

> This may be a little off topic, but does this, or any other framework,
> solve some testing inconveniences that exist in Clojure and probably other
> functional languages:
> 1) testing recursive functions. I want to test what a recursion STEP does,
> not the whole function. Can I mock 'recur'?
> 2) testing sequence, esp. lazy
> 3) IoC typically makes code more testable. What are Clojure alternatives
> for IoC? Pass all dependencies as parameters to your function?
>
> I wonder if code=data philosophy of Lisp enables some testing techniques
> that are impossible in languages like Java. Typically you can only test a
> function programmatically, not arbitrary code block. But you can probably
> introspect code very easily in Clojure, and test parts, regardless if they
> are functions or not. A test framework could support that in principle...
>
> I found that functional code is harder to separate, which would make it
> harder to test...
>
> Any thoughts?
> Thanks,
> Julian
>
>  --
> --
> 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/groups/opt_out.
>
>
>



-- 
“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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Brian Marick]

On Jun 10, 2013, at 12:22 AM, julianrz  wrote:

> This may be a little off topic, but does this, or any other framework, solve 
> some testing inconveniences that exist in Clojure and probably other 
> functional languages:
> 1) testing recursive functions. I want to test what a recursion STEP does, 
> not the whole function. Can I mock 'recur'?
> 3) IoC typically makes code more testable. What are Clojure alternatives for 
> IoC? Pass all dependencies as parameters to your function? 

You can do both of these things in Midje. Midje replaces inversion of control 
(3) with the metaphor of facts-about-functions that depend on facts about other 
functions (much as a proof might depend on a lemma). See
https://github.com/marick/Midje/wiki/The-idea-behind-top-down-development

That given, testing a recursive function (1) becomes a special case: 
https://github.com/marick/Midje/wiki/Partial-prerequisites

> 2) testing sequence, esp. lazy


You'll have to be more specific.


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

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Meikel Brandmeyer (kotarak)]

I sense a misunderstanding of transients in this message.

Am Sonntag, 9. Juni 2013 18:51:00 UTC+2 schrieb Steven Degutis:
>
> Thanks for the feedback. I'l look into #1. Regarding #2, we just wanted a 
> side-effecty (mutable) way of adding assertion-results within a test. I 
> suppose I could use (trans []) and let users use conj! although the fact 
> that transient keeps saying "alpha, use at your own risk" concerns me a bit.
>
>
Transients are supposed to be used like their normal counterparts: in a 
functional way. So you won't get around a reference type. Transients are a 
pure optimisation when constructing a data structure. They are not intended 
as faster drop-in replacement.

Kind regards
Meikel
 

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Peter Taoussanis]

Ooh, okay a little off topic here, but Expectations looks fantastic. Thanks 
a lot Jay!

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[julianrz]

This may be a little off topic, but does this, or any other framework, 
solve some testing inconveniences that exist in Clojure and probably other 
functional languages:
1) testing recursive functions. I want to test what a recursion STEP does, 
not the whole function. Can I mock 'recur'?
2) testing sequence, esp. lazy
3) IoC typically makes code more testable. What are Clojure alternatives 
for IoC? Pass all dependencies as parameters to your function? 

I wonder if code=data philosophy of Lisp enables some testing techniques 
that are impossible in languages like Java. Typically you can only test a 
function programmatically, not arbitrary code block. But you can probably 
introspect code very easily in Clojure, and test parts, regardless if they 
are functions or not. A test framework could support that in principle...

I found that functional code is harder to separate, which would make it 
harder to test... 

Any thoughts?
Thanks,
Julian  

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Then I apologize. I must have conflated what you said with what someone 
else said. My mistake.

On Sunday, June 9, 2013 8:38:22 PM UTC-5, Jay Fields wrote:
>
> On Sunday, June 9, 2013 8:50:46 PM UTC-4, Steven Degutis wrote:
>
>> But that's what I meant, that he's proposing we start with his lib and 
>> add extensibility in the places we want it. So my response to that still 
>> applies.
>
>
> That's not at all what I said, proposed, alluded to, or anything of the 
> sort.  
>
> I'll use quotes, perhaps that will make things easier - though I'm 
> skeptical at this point.
>
> You said: "..were frustrated with the inflexibility of existing libs.."
>
> I pointed out: "..expectations* has 0 open pull requests, 0 open issues, 
> and is very actively maintained.."
>
> Further, I wanted to make sure it was clear that "..anyone who chooses to 
> use expectations should feel free to contact me with any suggestions.."
>
> That's the only thing I said. I have no desire to integrate with test2.
>
> I'll leave it at that.
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Sean Corfield]

No. Read http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go

On Sun, Jun 9, 2013 at 6:41 PM, Steven Degutis  wrote:
> Is this still current? http://clojure.github.io/clojure-contrib/
>
> On Sunday, June 9, 2013 8:19:15 PM UTC-5, Sean Corfield wrote:
>>
>> On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis  wrote:
>> > Changing clojure.test seems like the wrong way to go. Being attached to
>> > a CA
>> > makes it hard to contribute to.
>>
>> It's a one-off action. Sign it, send it in. Then you can contribute to
>> Clojure or any of its contrib libraries from then on. Not exactly
>> "hard".
>>
>> > Being attached to Clojure makes it too slow-moving.
>>
>> Not true. Go look at the contrib libraries and see how they have
>> evolved. Nothing holds them back. The number of contributors - and the
>> number of libraries - is growing all the time.
>>
>> > I think everyone involved in the IRC discussion agreed that clojure.test
>> > should be deprecated it in favor of a backward-compatible, faster-moving
>> > successor. I'm certainly all for it.
>>
>> A backward-compatible, faster-moving successor is certainly possible
>> within the contrib system. It is more likely to be used as a
>> dependency by other libraries and it is more discoverable.
>>
>> > But maybe being a contrib-lib isn't a bad idea. I really
>> > don't know much about them and how they work.
>>
>> Don't dismiss it until you know more about them and the process
>> involved. If clojure.test was replaced within the contrib context, I'd
>> be far more likely to contribute to it than to some random third-party
>> library.
>>
>> > But that's what I meant, that he's proposing we start with his lib and
>> > add
>> > extensibility in the places we want it. So my response to that still
>> > applies.
>>
>> Your response was to a point he didn't make.
>>
>> > In my experience, when a tool comes out that people think is genuinely
>> > better, these things work themselves out. See how nrepl.el replaced
>> > swank.
>> > How leiningen replaced cake. How ring+compojure placed webjure and
>> > others.
>> > How Clojure replaced Ruby and CL and Python for a lot of us.
>>
>> True, but none of those were part of Clojure or contrib - and
>> tools.nrepl IS part of contrib now.
>>
>> > The low number of JIRA tickets probably says more about JIRA than
>> > clojure.test. You said those 3 tickets were the only ones against
>> > clojure.test, but in the discussion there were many more complaints.
>>
>> Yes, people tend to complain but don't actually do anything about it -
>> they don't open tickets - so nothing gets done :)
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> 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/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Is this still current? http://clojure.github.io/clojure-contrib/

On Sunday, June 9, 2013 8:19:15 PM UTC-5, Sean Corfield wrote:
>
> On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis 
> > 
> wrote: 
> > Changing clojure.test seems like the wrong way to go. Being attached to 
> a CA 
> > makes it hard to contribute to. 
>
> It's a one-off action. Sign it, send it in. Then you can contribute to 
> Clojure or any of its contrib libraries from then on. Not exactly 
> "hard". 
>
> > Being attached to Clojure makes it too slow-moving. 
>
> Not true. Go look at the contrib libraries and see how they have 
> evolved. Nothing holds them back. The number of contributors - and the 
> number of libraries - is growing all the time. 
>
> > I think everyone involved in the IRC discussion agreed that clojure.test 
> > should be deprecated it in favor of a backward-compatible, faster-moving 
> > successor. I'm certainly all for it. 
>
> A backward-compatible, faster-moving successor is certainly possible 
> within the contrib system. It is more likely to be used as a 
> dependency by other libraries and it is more discoverable. 
>
> > But maybe being a contrib-lib isn't a bad idea. I really 
> > don't know much about them and how they work. 
>
> Don't dismiss it until you know more about them and the process 
> involved. If clojure.test was replaced within the contrib context, I'd 
> be far more likely to contribute to it than to some random third-party 
> library. 
>
> > But that's what I meant, that he's proposing we start with his lib and 
> add 
> > extensibility in the places we want it. So my response to that still 
> > applies. 
>
> Your response was to a point he didn't make. 
>
> > In my experience, when a tool comes out that people think is genuinely 
> > better, these things work themselves out. See how nrepl.el replaced 
> swank. 
> > How leiningen replaced cake. How ring+compojure placed webjure and 
> others. 
> > How Clojure replaced Ruby and CL and Python for a lot of us. 
>
> True, but none of those were part of Clojure or contrib - and 
> tools.nrepl IS part of contrib now. 
>
> > The low number of JIRA tickets probably says more about JIRA than 
> > clojure.test. You said those 3 tickets were the only ones against 
> > clojure.test, but in the discussion there were many more complaints. 
>
> Yes, people tend to complain but don't actually do anything about it - 
> they don't open tickets - so nothing gets done :) 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

On Sunday, June 9, 2013 8:50:46 PM UTC-4, Steven Degutis wrote:

> But that's what I meant, that he's proposing we start with his lib and add 
> extensibility in the places we want it. So my response to that still 
> applies.


That's not at all what I said, proposed, alluded to, or anything of the 
sort.  

I'll use quotes, perhaps that will make things easier - though I'm 
skeptical at this point.

You said: "..were frustrated with the inflexibility of existing libs.."

I pointed out: "..expectations* has 0 open pull requests, 0 open issues, 
and is very actively maintained.."

Further, I wanted to make sure it was clear that "..anyone who chooses to 
use expectations should feel free to contact me with any suggestions.."

That's the only thing I said. I have no desire to integrate with test2.

I'll leave it at that.

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Sean Corfield]

On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis  wrote:
> Changing clojure.test seems like the wrong way to go. Being attached to a CA
> makes it hard to contribute to.

It's a one-off action. Sign it, send it in. Then you can contribute to
Clojure or any of its contrib libraries from then on. Not exactly
"hard".

> Being attached to Clojure makes it too slow-moving.

Not true. Go look at the contrib libraries and see how they have
evolved. Nothing holds them back. The number of contributors - and the
number of libraries - is growing all the time.

> I think everyone involved in the IRC discussion agreed that clojure.test
> should be deprecated it in favor of a backward-compatible, faster-moving
> successor. I'm certainly all for it.

A backward-compatible, faster-moving successor is certainly possible
within the contrib system. It is more likely to be used as a
dependency by other libraries and it is more discoverable.

> But maybe being a contrib-lib isn't a bad idea. I really
> don't know much about them and how they work.

Don't dismiss it until you know more about them and the process
involved. If clojure.test was replaced within the contrib context, I'd
be far more likely to contribute to it than to some random third-party
library.

> But that's what I meant, that he's proposing we start with his lib and add
> extensibility in the places we want it. So my response to that still
> applies.

Your response was to a point he didn't make.

> In my experience, when a tool comes out that people think is genuinely
> better, these things work themselves out. See how nrepl.el replaced swank.
> How leiningen replaced cake. How ring+compojure placed webjure and others.
> How Clojure replaced Ruby and CL and Python for a lot of us.

True, but none of those were part of Clojure or contrib - and
tools.nrepl IS part of contrib now.

> The low number of JIRA tickets probably says more about JIRA than
> clojure.test. You said those 3 tickets were the only ones against
> clojure.test, but in the discussion there were many more complaints.

Yes, people tend to complain but don't actually do anything about it -
they don't open tickets - so nothing gets done :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

> Are there any JIRA tickets open against clojure.test? That would seem 
> to be a good place to start. 
>

Good idea, that helps for gathering data about use-cases.
 

> If someone (with a signed CA on file) wants to step up and maintain 
> clojure.test, even tho' it's part of core Clojure right now, I expect 
> a way to move forward with that could be found? Perhaps adding 
> test.core as a new contrib library as a copy of clojure.test and 
> deprecating clojure.test? 
>

Changing clojure.test seems like the wrong way to go. Being attached to a 
CA makes it hard to contribute to. Being attached to Clojure makes it too 
slow-moving.

I think everyone involved in the IRC discussion agreed that clojure.test 
should be deprecated it in favor of a backward-compatible, faster-moving 
successor. I'm certainly all for it.
 

> But there is of course the basic question of whether a testing 
> framework should be part of Clojure itself (as it is now) vs a contrib 
> library (as test.generative is now) vs a third party library (as 
> Midje, Expectations, Conjecture and others are right now). 
>

Being a third-party lib seems to me like the easiest way for it to grow and 
evolve properly. But maybe being a contrib-lib isn't a bad idea. I really 
don't know much about them and how they work.
  

> > You're suggesting we should have started with your lib and proposed 
> changes. 
>
> I don't think that's what Jay is saying. I certainly didn't interpret 
> his post that way. I think all he was saying - and I think all Brian 
> is saying about Midje - is that people aren't asking them for the kind 
> of extension points etc that you seem to want for test2.


But that's what I meant, that he's proposing we start with his lib and add 
extensibility in the places we want it. So my response to that still 
applies.
 

> Personally, I 
> think Midje is too complicated for my needs - but it's certainly very 
> slick - so although I've looked at it a couple of times, I've never 
> felt like adopting it. At World Singles, we started out with 
> clojure.test by default and just over a year ago converted our entire 
> test suite to Expectations instead because it's simpler and cleaner 
> and much, much easier to read than clojure.test. We since wrote a 
> whole bunch of tests based on clj-webdriver to replace some Selenium 
> (HTML-based) tests and clojure.test is a better fit there so we've 
> started using it again, just for that. [specifically, our webdriver 
> tests tend to be "do a bunch of browser stuff", "assert some 
> conditions with `is`", "do more browser stuff", "assert more stuff", 
> "click around some more", "assert some more", etc] 
>

Think about it this way: you really just wanted to change how assertions 
were written. But you had to switch libs entirely. With test2, you'd just 
have to add a new dependency, and start writing new tests with the new 
assertion functions, while the old tests kept on working. Then you could 
rewrite old tests progressively. Until that was done, they could live side 
by side in your project comfortably. That's part of the goal of test2.
 

> Is there room for another testing framework? Certainly. Could 
> clojure.test be improved? Definitely. Is there some standalone 
> infrastructure that all testing frameworks could be based on? Maybe. 
> Is that compelling enough that other testing framework authors would 
> rewrite their libraries in terms of some common infrastructure? Given 
> their existing libraries work just fine - and there are Emacs modes 
> and auto runners for them already - I'm very skeptical. 
>

In my experience, when a tool comes out that people think is genuinely 
better, these things work themselves out. See how nrepl.el replaced swank. 
How leiningen replaced cake. How ring+compojure placed webjure and others. 
How Clojure replaced Ruby and CL and Python for a lot of us.

When people believe in a tool, extensions for it will get written. Emacs 
plugins will get written or adapted. They'll do it because they really want 
to use it.

I admit that this point won't come until it's actually got several 
extensions written to prove it's worth. That task probably falls on me for 
a little while, until the ball gets rolling.
 

> On the other hand, there are definitely compelling tools that would 
> benefit from a common data structure for test run reports: displaying 
> results / failures to the console, feeding to JUnit HTML report 
> formatters (where current frameworks are pretty weak), supporting a 
> standard way to display red/green results in editors and IDEs (again, 
> existing frameworks are weak here). 
>

Right! Being able to do these things is one of the main points!
 

> My point is that folks either use clojure.test (and may grumble a bit 
> about its shortcomings - but not much based on how few JIRA tickets 
> exist) or they switch to a third party framework they prefer - but 
> across the board tooling is the weak spot (IMO). So I wouldn't spend 
> muc

Re: [pre-ANN] test2, the last Clojure testing framework

[Sean Corfield]

FWIW, about the only thing about clojure.test that I miss occasionally
when using Expectations is 'each' fixtures for a subset of tests but
the work involved in wrapping an expression in a try/finally with the
resource setup and tear down I need is usually so minimal that's it's
not even worth writing a macro to standardize the boilerplate (at
least, it hasn't annoyed me sufficiently to make it worth doing yet).

Sean

On Sun, Jun 9, 2013 at 4:57 PM, Steven Degutis  wrote:
> I agree, we should survey users of existing tools. The thing is, we *are*
> those users. The aforementioned brainstorming session was just what you're
> suggesting. That's what I'm suggesting this mailing list thread be.
>
> For example, I never use Midje's "a => b" outside of a macro. I always wrap
> fact around it like "(fact a => b)". Firstly because it's clearer to skim
> for assertions this way. Secondly it works much better with paredit. Now you
> know how I feel about Midje. If more people chime in with thoughts like
> this, then we'll have pretty good data to start with.
>
> -Steven
>
> On Sunday, June 9, 2013 6:11:38 PM UTC-5, Brian Marick wrote:
>>
>>
>> On Jun 9, 2013, at 1:07 PM, Steven Degutis  wrote:
>> > I think we all agree that it's extremely important to discuss the SPEC
>> > as a community. In fact, since this is a pre-ANN, let's consider this 
>> > thread
>> > the perfect place for such a discussion.
>>
>> I suggest that surveying users of the various existing tools for how they
>> use them and what they want is a more important first step than worrying
>> about a data model.
>>
>> For example, it would be good to know what parts of Midje that I
>> personally obsess about are in fact unimportant to the typical user.
>>
>> Although open source projects (Midje, certainly) are about one's own itch,
>> it also helps to see where the users are scratching.
>>
>> 
>> Latest book: /Functional Programming for the Object-Oriented Programmer/
>> https://leanpub.com/fp-oo
>>
> --
> --
> 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/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

I agree, we should survey users of existing tools. The thing is, we *are* 
those users. The aforementioned brainstorming session was just what you're 
suggesting. That's what I'm suggesting this mailing list thread be.

For example, I never use Midje's "a => b" outside of a macro. I always wrap 
fact around it like "(fact a => b)". Firstly because it's clearer to skim 
for assertions this way. Secondly it works much better with paredit. Now 
you know how I feel about Midje. If more people chime in with thoughts like 
this, then we'll have pretty good data to start with.

-Steven

On Sunday, June 9, 2013 6:11:38 PM UTC-5, Brian Marick wrote:
>
>
> On Jun 9, 2013, at 1:07 PM, Steven Degutis > 
> wrote: 
> > I think we all agree that it's extremely important to discuss the SPEC 
> as a community. In fact, since this is a pre-ANN, let's consider this 
> thread the perfect place for such a discussion. 
>
> I suggest that surveying users of the various existing tools for how they 
> use them and what they want is a more important first step than worrying 
> about a data model. 
>
> For example, it would be good to know what parts of Midje that I 
> personally obsess about are in fact unimportant to the typical user. 
>
> Although open source projects (Midje, certainly) are about one's own itch, 
> it also helps to see where the users are scratching. 
>
>  
> Latest book: /Functional Programming for the Object-Oriented Programmer/ 
> https://leanpub.com/fp-oo 
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Sean Corfield]

On Sun, Jun 9, 2013 at 11:07 AM, Steven Degutis  wrote:
> We realized we can't change clojure.test because (1) this would break
> backwards compatibility, and (2) clojure.test is really slow-moving since it
> lives inside Clojure.

Are there any JIRA tickets open against clojure.test? That would seem
to be a good place to start.

There seem to be just three against clojure.test:

CLJ-840 Add a way to access the current test var in :each fixtures for
clojure.test
CLJ-866 Provide a clojure.test function to run a single test case with fixtures
CLJ-1209 Teach clojure.test reporting about ex-info/ex-data

Sounds like CLJ-866 was covered in the discussions around test2 - not
sure about the others?

If someone (with a signed CA on file) wants to step up and maintain
clojure.test, even tho' it's part of core Clojure right now, I expect
a way to move forward with that could be found? Perhaps adding
test.core as a new contrib library as a copy of clojure.test and
deprecating clojure.test?

But there is of course the basic question of whether a testing
framework should be part of Clojure itself (as it is now) vs a contrib
library (as test.generative is now) vs a third party library (as
Midje, Expectations, Conjecture and others are right now).

> This is when we realized that, if done right, test2 could be flexible enough
> where Midje/Speclj/Expectations could be re-written as extensions to test2.

I don't know whether a "core" testing library would offer enough
commonality that those frameworks' authors would consider a rewrite to
depend on a separate testing library worthwhile? Perhaps if it was a
Clojure contrib library they might?

> You're suggesting we should have started with your lib and proposed changes.

I don't think that's what Jay is saying. I certainly didn't interpret
his post that way. I think all he was saying - and I think all Brian
is saying about Midje - is that people aren't asking them for the kind
of extension points etc that you seem to want for test2. Personally, I
think Midje is too complicated for my needs - but it's certainly very
slick - so although I've looked at it a couple of times, I've never
felt like adopting it. At World Singles, we started out with
clojure.test by default and just over a year ago converted our entire
test suite to Expectations instead because it's simpler and cleaner
and much, much easier to read than clojure.test. We since wrote a
whole bunch of tests based on clj-webdriver to replace some Selenium
(HTML-based) tests and clojure.test is a better fit there so we've
started using it again, just for that. [specifically, our webdriver
tests tend to be "do a bunch of browser stuff", "assert some
conditions with `is`", "do more browser stuff", "assert more stuff",
"click around some more", "assert some more", etc]

Is there room for another testing framework? Certainly. Could
clojure.test be improved? Definitely. Is there some standalone
infrastructure that all testing frameworks could be based on? Maybe.
Is that compelling enough that other testing framework authors would
rewrite their libraries in terms of some common infrastructure? Given
their existing libraries work just fine - and there are Emacs modes
and auto runners for them already - I'm very skeptical.

On the other hand, there are definitely compelling tools that would
benefit from a common data structure for test run reports: displaying
results / failures to the console, feeding to JUnit HTML report
formatters (where current frameworks are pretty weak), supporting a
standard way to display red/green results in editors and IDEs (again,
existing frameworks are weak here).

My point is that folks either use clojure.test (and may grumble a bit
about its shortcomings - but not much based on how few JIRA tickets
exist) or they switch to a third party framework they prefer - but
across the board tooling is the weak spot (IMO). So I wouldn't spend
much time on the test machinery itself and the API that test2 exposes
since that's all very subjective - but I think the test result SPEC is
potentially very fruitful and could benefit all the frameworks...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: [pre-ANN] test2, the last Clojure testing framework

[Brian Marick]

On Jun 9, 2013, at 1:07 PM, Steven Degutis  wrote:
> I think we all agree that it's extremely important to discuss the SPEC as a 
> community. In fact, since this is a pre-ANN, let's consider this thread the 
> perfect place for such a discussion.

I suggest that surveying users of the various existing tools for how they use 
them and what they want is a more important first step than worrying about a 
data model. 

For example, it would be good to know what parts of Midje that I personally 
obsess about are in fact unimportant to the typical user.

Although open source projects (Midje, certainly) are about one's own itch, it 
also helps to see where the users are scratching. 


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

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

There's a few things that I know the SPEC needs to address.

- Pending tests

- Some flexible concept of around-all and around-each that allow separating 
Definers from Runners (currently, to implement clojure.test's 
once-fixtures, it requires a custom Definer *and* a custom Runner)

- Whether Runners should pass lazy sequences to Reports

- Being able to compose runners somehow (i.e. have an auto-runner that also 
runs them in random order, and runs tests in their own threads, three 
different runners being used together)

Thoughts?

-Steven

On Sunday, June 9, 2013 1:07:20 PM UTC-5, Steven Degutis wrote:
>
> Jay (and others),
>
> First of all, you must understand where test2 came from. It started as a 
> bunch of people** in #clojure discussing what we'd change about 
> clojure.test if we could.
>
> We realized we can't change clojure.test because (1) this would break 
> backwards compatibility, and (2) clojure.test is really slow-moving since 
> it lives inside Clojure. So the idea was to create a successor to 
> clojure.test with the changes we wanted, and which didn't live inside 
> Clojure. Hence the name test2.
>
> These very smart people were brainstorming for a few hours, and came up 
> with some really good ideas. I started organizing their thoughts in a wiki, 
> and was trying to guide the discussion with some provoking questions.
>
> Two high-level concepts kept recurring in the discussion. First, it should 
> be really simple, building on Clojure concepts, and not using any special 
> magic. The second one naturally follows from this: if it's just plain old 
> no-magic Clojure, you can easily build on top of it. In other words, you 
> get extensibility for free.
>
> This is when we realized that, if done right, test2 could be flexible 
> enough where Midje/Speclj/Expectations could be re-written as extensions to 
> test2. Or you could just use vanilla test2 similarly to clojure.test. Or 
> you can mix and match extensions.
>
> Let me briefly say that I don't consider test2 to be my project. All I did 
> was turn their ideas into a 
> SPECand some code. 
> I knew that everyone involved was too busy to do it, even 
> though they wanted it to exist. So I jumped in and did my small part.
>
> You're suggesting we should have started with your lib and proposed 
> changes. Let's generalize this for a second and say "with anyone else's 
> lib" since there are other test-lib authors who might say the same thing. 
> First of all, whose lib should we start with? Picking any existing one 
> gives an unfair bias toward that lib's feature-set. Second of all, when a 
> feature-set changes this drastically, it's usually clearer to see best 
> solution from a blank slate. Third of all, this is intended to be a 
> community-controlled lib, but each existing lib already has an owner in 
> full control.
>
> But you're right. I shouldn't have just assumed the SPEC is ready and 
> started calling for extensions. Sure, the initial conversation in IRC gave 
> us a really solid starting-point, but let's admit that the SPEC isn't ready 
> yet and needs work. I apologize for being so naive.
>
> I think we all agree that it's extremely important to discuss the SPEC as 
> a community. In fact, since this is a pre-ANN, let's consider this thread 
> the perfect place for such a discussion.
>
> For example, in its current incarnation, having once-fixtures a la 
> clojure.test requires a custom runner, but it should really be part of a 
> Definer's role. And there's some confusion as to whether Runners should 
> give Reporters a lazy sequence of test-results or not, which would mean not 
> actually running each test until the Reporter needs them to be run. Or, 
> maybe the 4 roles defined in the SPEC are inadequate in the first place and 
> need to be changed up somewhat.
>
> ** I'm not going to drop names in case they don't want to be part of this 
> discussion, but maybe they'll come in here and affirm that what I'm saying 
> isn't self-serving BS, but that it's all true and an accurate 
> representation of the events.
>
> -Steven
>
>
> On Sun, Jun 9, 2013 at 11:45 AM, Jay Fields wrote:
>
>> I'd like to mention that expectations* has 0 open pull requests, 0 open 
>> issues, and is very actively maintained**. Steven, I don't want to 
>> discourage you from creating your own testing framework, I think everyone 
>> should, it's a very educational experience.
>>
>> I just wanted to be clear that no one has ever asked me for any help 
>> extending expectations, and anyone who chooses to use expectations should 
>> feel free to contact me with any suggestions.
>>
>> * https://github.com/jaycfields/expectations
>> ** https://github.com/jaycfields/expectations/commits/master
>>
>>
>> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>>>
>>> Test2 is a new testing lib for Clojure, where the power is its 
>>> simplicity, extensibility, and a 
>>> SPEC

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Jay (and others),

First of all, you must understand where test2 came from. It started as a
bunch of people** in #clojure discussing what we'd change about
clojure.test if we could.

We realized we can't change clojure.test because (1) this would break
backwards compatibility, and (2) clojure.test is really slow-moving since
it lives inside Clojure. So the idea was to create a successor to
clojure.test with the changes we wanted, and which didn't live inside
Clojure. Hence the name test2.

These very smart people were brainstorming for a few hours, and came up
with some really good ideas. I started organizing their thoughts in a wiki,
and was trying to guide the discussion with some provoking questions.

Two high-level concepts kept recurring in the discussion. First, it should
be really simple, building on Clojure concepts, and not using any special
magic. The second one naturally follows from this: if it's just plain old
no-magic Clojure, you can easily build on top of it. In other words, you
get extensibility for free.

This is when we realized that, if done right, test2 could be flexible
enough where Midje/Speclj/Expectations could be re-written as extensions to
test2. Or you could just use vanilla test2 similarly to clojure.test. Or
you can mix and match extensions.

Let me briefly say that I don't consider test2 to be my project. All I did
was turn their ideas into a
SPECand some
code. I knew that everyone involved was too busy to do it, even
though they wanted it to exist. So I jumped in and did my small part.

You're suggesting we should have started with your lib and proposed
changes. Let's generalize this for a second and say "with anyone else's
lib" since there are other test-lib authors who might say the same thing.
First of all, whose lib should we start with? Picking any existing one
gives an unfair bias toward that lib's feature-set. Second of all, when a
feature-set changes this drastically, it's usually clearer to see best
solution from a blank slate. Third of all, this is intended to be a
community-controlled lib, but each existing lib already has an owner in
full control.

But you're right. I shouldn't have just assumed the SPEC is ready and
started calling for extensions. Sure, the initial conversation in IRC gave
us a really solid starting-point, but let's admit that the SPEC isn't ready
yet and needs work. I apologize for being so naive.

I think we all agree that it's extremely important to discuss the SPEC as a
community. In fact, since this is a pre-ANN, let's consider this thread the
perfect place for such a discussion.

For example, in its current incarnation, having once-fixtures a la
clojure.test requires a custom runner, but it should really be part of a
Definer's role. And there's some confusion as to whether Runners should
give Reporters a lazy sequence of test-results or not, which would mean not
actually running each test until the Reporter needs them to be run. Or,
maybe the 4 roles defined in the SPEC are inadequate in the first place and
need to be changed up somewhat.

** I'm not going to drop names in case they don't want to be part of this
discussion, but maybe they'll come in here and affirm that what I'm saying
isn't self-serving BS, but that it's all true and an accurate
representation of the events.

-Steven


On Sun, Jun 9, 2013 at 11:45 AM, Jay Fields  wrote:

> I'd like to mention that expectations* has 0 open pull requests, 0 open
> issues, and is very actively maintained**. Steven, I don't want to
> discourage you from creating your own testing framework, I think everyone
> should, it's a very educational experience.
>
> I just wanted to be clear that no one has ever asked me for any help
> extending expectations, and anyone who chooses to use expectations should
> feel free to contact me with any suggestions.
>
> * https://github.com/jaycfields/expectations
> ** https://github.com/jaycfields/expectations/commits/master
>
>
> On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>>
>> Test2 is a new testing lib for Clojure, where the power is its
>> simplicity, extensibility, and a 
>> SPEC much
>> like Ring's.
>>
>> Github: 
>> https://github.com/**evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with
>> the smart folks in #clojure, who were frustrated with the inflexibility of
>> existing libs, and intended this to be the spiritual successor to
>> clojure.test. We wanted something that was still simple like clojure.test,
>> but could be extended externally much more easily in case you wanted
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've
>> written one last night, 
>> test2-autorunner

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Thanks for the feedback. I'l look into #1. Regarding #2, we just wanted a 
side-effecty (mutable) way of adding assertion-results within a test. I 
suppose I could use (trans []) and let users use conj! although the fact 
that transient keeps saying "alpha, use at your own risk" concerns me a bit.

On Sunday, June 9, 2013 3:27:30 AM UTC-5, stuart@gmail.com wrote:
>
> Hi Steven,
>
> A few thoughts:
>
> 1. You may want to look at 
> https://github.com/clojure/test.generative/blob/master/data-model.org.
>
> 2. I don't think you want a ref for *assertion-results* -- I am not aware 
> of any use cases that would need transactions. In any case the choice of 
> reference type probably belongs in the impl, not the spec. 
>
> Good luck with this!
> Stu 
>
>
> On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis 
> > wrote:
>
>> Test2 is a new testing lib for Clojure, where the power is its 
>> simplicity, extensibility, and a 
>> SPEC much 
>> like Ring's.
>>
>> Github: https://github.com/evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  with 
>> the smart folks in #clojure, who were frustrated with the inflexibility of 
>> existing libs, and intended this to be the spiritual successor to 
>> clojure.test. We wanted something that was still simple like clojure.test, 
>> but could be extended externally much more easily in case you wanted 
>> features found in clojure.test, Midje, Speclj, or Expectations, or whatever 
>> else.
>>
>> This is a pre-ANN because it's more of a call for extensions. I've 
>> written one last night, 
>> test2-autorunner, 
>> which took about an hour. This should give some idea of how easy it is and 
>> how well-designed the SPEC was by the smart folks of #clojure. There are 
>> some ideas at the bottom of the wiki, but of course any extensions are 
>> encouraged.
>>
>> -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 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

I'd like to mention that expectations* has 0 open pull requests, 0 open 
issues, and is very actively maintained**. Steven, I don't want to 
discourage you from creating your own testing framework, I think everyone 
should, it's a very educational experience.

I just wanted to be clear that no one has ever asked me for any help 
extending expectations, and anyone who chooses to use expectations should 
feel free to contact me with any suggestions.

* https://github.com/jaycfields/expectations
** https://github.com/jaycfields/expectations/commits/master

On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote:
>
> Test2 is a new testing lib for Clojure, where the power is its simplicity, 
> extensibility, and a 
> SPEC much 
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> with 
> the smart folks in #clojure, who were frustrated with the inflexibility of 
> existing libs, and intended this to be the spiritual successor to 
> clojure.test. We wanted something that was still simple like clojure.test, 
> but could be extended externally much more easily in case you wanted 
> features found in clojure.test, Midje, Speclj, or Expectations, or whatever 
> else.
>
> This is a pre-ANN because it's more of a call for extensions. I've written 
> one last night, 
> test2-autorunner, 
> which took about an hour. This should give some idea of how easy it is and 
> how well-designed the SPEC was by the smart folks of #clojure. There are 
> some ideas at the bottom of the wiki, but of course any extensions are 
> encouraged.
>
> -Steven
>

-- 
-- 
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/groups/opt_out.

Re: [pre-ANN] test2, the last Clojure testing framework

[Stuart Halloway]

Hi Steven,

A few thoughts:

1. You may want to look at
https://github.com/clojure/test.generative/blob/master/data-model.org.

2. I don't think you want a ref for *assertion-results* -- I am not aware
of any use cases that would need transactions. In any case the choice of
reference type probably belongs in the impl, not the spec.

Good luck with this!
Stu


On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis  wrote:

> Test2 is a new testing lib for Clojure, where the power is its simplicity,
> extensibility, and a 
> SPEC much
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> with
> the smart folks in #clojure, who were frustrated with the inflexibility of
> existing libs, and intended this to be the spiritual successor to
> clojure.test. We wanted something that was still simple like clojure.test,
> but could be extended externally much more easily in case you wanted
> features found in clojure.test, Midje, Speclj, or Expectations, or whatever
> else.
>
> This is a pre-ANN because it's more of a call for extensions. I've written
> one last night, 
> test2-autorunner,
> which took about an hour. This should give some idea of how easy it is and
> how well-designed the SPEC was by the smart folks of #clojure. There are
> some ideas at the bottom of the wiki, but of course any extensions are
> encouraged.
>
> -Steven
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

[pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

Test2 is a new testing lib for Clojure, where the power is its simplicity, 
extensibility, and a 
SPEC much 
like Ring's.

Github: https://github.com/evanescence/test2

Some background: It came out of 
discussions 
with 
the smart folks in #clojure, who were frustrated with the inflexibility of 
existing libs, and intended this to be the spiritual successor to 
clojure.test. We wanted something that was still simple like clojure.test, 
but could be extended externally much more easily in case you wanted 
features found in clojure.test, Midje, Speclj, or Expectations, or whatever 
else.

This is a pre-ANN because it's more of a call for extensions. I've written 
one last night, 
test2-autorunner, 
which took about an hour. This should give some idea of how easy it is and 
how well-designed the SPEC was by the smart folks of #clojure. There are 
some ideas at the bottom of the wiki, but of course any extensions are 
encouraged.

-Steven

-- 
-- 
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/groups/opt_out.