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 
> SPEC<https://github.com/evanescence/test2/blob/master/SPEC.md>and 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<https://github.com/evanescence/test2/blob/master/SPEC.md> much 
>>> like Ring's.
>>>
>>> Github: 
>>> https://github.com/**evanescence/test2<https://github.com/evanescence/test2>
>>>
>>> Some background: It came out of 
>>> discussions<https://github.com/evanescence/test2/wiki/Communal-Brainstorming>
>>>  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<https://github.com/evanescence/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.


Reply via email to