librelist archives

« back to archive

litmus progress

litmus progress

From:
Tom Yandell
Date:
2011-05-01 @ 17:21
Have just push changes to use.no.de containing litmus docs. Not finished or
published to the site yet, but would still appreciate any feedback:

https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv

Also, I've sent a pull request to Miller Medeiros for getting JS Signals
into NPM. Going to wait for this to happen before integrating with litmus:

https://github.com/millermedeiros/js-signals/issues/20
https://github.com/millermedeiros/js-signals/issues/21

Tom

Re: [nug] litmus progress

From:
Michael
Date:
2011-05-02 @ 01:07
I'm very interested in testing libraries that are easy to run on either: 
node, rhino, or browser. Also I think the should.js syntax is cool. What 
makes litmus better/different than, oh say, nodeunit, for example?

On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:

> Have just push changes to use.no.de containing litmus docs. Not finished
or published to the site yet, but would still appreciate any feedback:
> 
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> 
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
into NPM. Going to wait for this to happen before integrating with litmus:
> 
> https://github.com/millermedeiros/js-signals/issues/20
> https://github.com/millermedeiros/js-signals/issues/21
> 
> Tom

Re: [nug] litmus progress

From:
Richard Hodgson
Date:
2011-05-02 @ 02:31
Hmm...I still don't like testing libraries (like should.js) that
extend Object - separation is a good thing.

Tom, will Litmus run in both browser and nodejs?

On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> I'm very interested in testing libraries that are easy to run on either:
> node, rhino, or browser. Also I think the should.js syntax is cool. What
> makes litmus better/different than, oh say, nodeunit, for example?
>
> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>
> Have just push changes to use.no.de containing litmus docs. Not finished or
> published to the site yet, but would still appreciate any feedback:
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> into NPM. Going to wait for this to happen before integrating with litmus:
> https://github.com/millermedeiros/js-signals/issues/20
> https://github.com/millermedeiros/js-signals/issues/21
> Tom

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 06:25
It used to when it was using pkg. Now there are a couple of steps necessary
to make it work:

* A build system that creates an amd package/packages usable in the browser.
* Work on lib/browser.js (not yet ported from pkg) to load, run and display
tests in the browser (the planned js-signals integration will make this more
fun).
* A way to load and compose tests into suites that does not use synchronous
require statements.

This is on my list, but I'd like to spend some time thinking about how BDD
fits into it first. I love gherkin syntax, but think separate features
doesn't make sense for unit tests. Would like to do something like:

this.feature('name of feature', function () {
    /*
        Given ...
        When ...
        Then ...
    */

     // code that tests the feature
});

..although that's just thinking out loud.

Tom

On 2 May 2011 03:31, Richard Hodgson <rightaboutnow@gmail.com> wrote:

> Hmm...I still don't like testing libraries (like should.js) that
> extend Object - separation is a good thing.
>
> Tom, will Litmus run in both browser and nodejs?
>
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > I'm very interested in testing libraries that are easy to run on either:
> > node, rhino, or browser. Also I think the should.js syntax is cool. What
> > makes litmus better/different than, oh say, nodeunit, for example?
> >
> > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
> >
> > Have just push changes to use.no.de containing litmus docs. Not finished
> or
> > published to the site yet, but would still appreciate any feedback:
> > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> >
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> > into NPM. Going to wait for this to happen before integrating with
> litmus:
> > https://github.com/millermedeiros/js-signals/issues/20
> > https://github.com/millermedeiros/js-signals/issues/21
> > Tom
>

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 06:56
To see the docs in more pleasant surroundings:

http://september.mine.nu/litmus

Thanks Rich, sorry for not waiting for you to mention it, but it looks very
cool. Only thing i would say is that perhaps the project nav should be at
the top, but still subsidiary - i.e. not like the main nav, just links to
other projects? What do you think?

Thanks

Tom

On 2 May 2011 07:25, Tom Yandell <tom@yandell.me.uk> wrote:

> It used to when it was using pkg. Now there are a couple of steps necessary
> to make it work:
>
> * A build system that creates an amd package/packages usable in the
> browser.
> * Work on lib/browser.js (not yet ported from pkg) to load, run and display
> tests in the browser (the planned js-signals integration will make this more
> fun).
> * A way to load and compose tests into suites that does not use synchronous
> require statements.
>
> This is on my list, but I'd like to spend some time thinking about how BDD
> fits into it first. I love gherkin syntax, but think separate features
> doesn't make sense for unit tests. Would like to do something like:
>
> this.feature('name of feature', function () {
>     /*
>         Given ...
>         When ...
>         Then ...
>     */
>
>      // code that tests the feature
> });
>
> ..although that's just thinking out loud.
>
> Tom
>
> On 2 May 2011 03:31, Richard Hodgson <rightaboutnow@gmail.com> wrote:
>
>> Hmm...I still don't like testing libraries (like should.js) that
>> extend Object - separation is a good thing.
>>
>> Tom, will Litmus run in both browser and nodejs?
>>
>> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>> > I'm very interested in testing libraries that are easy to run on either:
>> > node, rhino, or browser. Also I think the should.js syntax is cool. What
>> > makes litmus better/different than, oh say, nodeunit, for example?
>> >
>> > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>> >
>> > Have just push changes to use.no.de containing litmus docs. Not
>> finished or
>> > published to the site yet, but would still appreciate any feedback:
>> > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
>> >
>> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>> > Also, I've sent a pull request to Miller Medeiros for getting JS Signals
>> > into NPM. Going to wait for this to happen before integrating with
>> litmus:
>> > https://github.com/millermedeiros/js-signals/issues/20
>> > https://github.com/millermedeiros/js-signals/issues/21
>> > Tom
>>
>
>

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 06:58
Also, let me know when you're ready to merge into the master branch :-)

Tom

On 2 May 2011 07:56, Tom Yandell <tom@yandell.me.uk> wrote:

> To see the docs in more pleasant surroundings:
>
> http://september.mine.nu/litmus
>
> Thanks Rich, sorry for not waiting for you to mention it, but it looks very
> cool. Only thing i would say is that perhaps the project nav should be at
> the top, but still subsidiary - i.e. not like the main nav, just links to
> other projects? What do you think?
>
> Thanks
>
> Tom
>
>
> On 2 May 2011 07:25, Tom Yandell <tom@yandell.me.uk> wrote:
>
>> It used to when it was using pkg. Now there are a couple of steps
>> necessary to make it work:
>>
>> * A build system that creates an amd package/packages usable in the
>> browser.
>> * Work on lib/browser.js (not yet ported from pkg) to load, run and
>> display tests in the browser (the planned js-signals integration will make
>> this more fun).
>> * A way to load and compose tests into suites that does not use
>> synchronous require statements.
>>
>> This is on my list, but I'd like to spend some time thinking about how BDD
>> fits into it first. I love gherkin syntax, but think separate features
>> doesn't make sense for unit tests. Would like to do something like:
>>
>> this.feature('name of feature', function () {
>>     /*
>>         Given ...
>>         When ...
>>         Then ...
>>     */
>>
>>      // code that tests the feature
>> });
>>
>> ..although that's just thinking out loud.
>>
>> Tom
>>
>> On 2 May 2011 03:31, Richard Hodgson <rightaboutnow@gmail.com> wrote:
>>
>>> Hmm...I still don't like testing libraries (like should.js) that
>>> extend Object - separation is a good thing.
>>>
>>> Tom, will Litmus run in both browser and nodejs?
>>>
>>> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>>> > I'm very interested in testing libraries that are easy to run on
>>> either:
>>> > node, rhino, or browser. Also I think the should.js syntax is cool.
>>> What
>>> > makes litmus better/different than, oh say, nodeunit, for example?
>>> >
>>> > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>>> >
>>> > Have just push changes to use.no.de containing litmus docs. Not
>>> finished or
>>> > published to the site yet, but would still appreciate any feedback:
>>> > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
>>> >
>>> 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>>> > Also, I've sent a pull request to Miller Medeiros for getting JS
>>> Signals
>>> > into NPM. Going to wait for this to happen before integrating with
>>> litmus:
>>> > https://github.com/millermedeiros/js-signals/issues/20
>>> > https://github.com/millermedeiros/js-signals/issues/21
>>> > Tom
>>>
>>
>>
>

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 07:10
Getting slightly off topic, but I also like the docs you get when you click
"getting started". Feel free to yoink parts of the old getting started with
micro and spectrum tutorial into the (currently non-existant) spectrum part
and remove it.

Another thing we could work in somewhere (I'm not sure where) is links to
other projects that work well in conjunction with this set of technologies:

promised-io
js-signals
jsdoc
socket-io
etc.

Tom

On 2 May 2011 07:58, Tom Yandell <tom@yandell.me.uk> wrote:

> Also, let me know when you're ready to merge into the master branch :-)
>
> Tom
>
> On 2 May 2011 07:56, Tom Yandell <tom@yandell.me.uk> wrote:
>
>> To see the docs in more pleasant surroundings:
>>
>> http://september.mine.nu/litmus
>>
>> Thanks Rich, sorry for not waiting for you to mention it, but it looks
>> very cool. Only thing i would say is that perhaps the project nav should be
>> at the top, but still subsidiary - i.e. not like the main nav, just links to
>> other projects? What do you think?
>>
>> Thanks
>>
>> Tom
>>
>>
>> On 2 May 2011 07:25, Tom Yandell <tom@yandell.me.uk> wrote:
>>
>>> It used to when it was using pkg. Now there are a couple of steps
>>> necessary to make it work:
>>>
>>> * A build system that creates an amd package/packages usable in the
>>> browser.
>>> * Work on lib/browser.js (not yet ported from pkg) to load, run and
>>> display tests in the browser (the planned js-signals integration will make
>>> this more fun).
>>> * A way to load and compose tests into suites that does not use
>>> synchronous require statements.
>>>
>>> This is on my list, but I'd like to spend some time thinking about how
>>> BDD fits into it first. I love gherkin syntax, but think separate features
>>> doesn't make sense for unit tests. Would like to do something like:
>>>
>>> this.feature('name of feature', function () {
>>>     /*
>>>         Given ...
>>>         When ...
>>>         Then ...
>>>     */
>>>
>>>      // code that tests the feature
>>> });
>>>
>>> ..although that's just thinking out loud.
>>>
>>> Tom
>>>
>>> On 2 May 2011 03:31, Richard Hodgson <rightaboutnow@gmail.com> wrote:
>>>
>>>> Hmm...I still don't like testing libraries (like should.js) that
>>>> extend Object - separation is a good thing.
>>>>
>>>> Tom, will Litmus run in both browser and nodejs?
>>>>
>>>> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>>>> > I'm very interested in testing libraries that are easy to run on
>>>> either:
>>>> > node, rhino, or browser. Also I think the should.js syntax is cool.
>>>> What
>>>> > makes litmus better/different than, oh say, nodeunit, for example?
>>>> >
>>>> > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>>>> >
>>>> > Have just push changes to use.no.de containing litmus docs. Not
>>>> finished or
>>>> > published to the site yet, but would still appreciate any feedback:
>>>> > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
>>>> >
>>>> 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>>>> > Also, I've sent a pull request to Miller Medeiros for getting JS
>>>> Signals
>>>> > into NPM. Going to wait for this to happen before integrating with
>>>> litmus:
>>>> > https://github.com/millermedeiros/js-signals/issues/20
>>>> > https://github.com/millermedeiros/js-signals/issues/21
>>>> > Tom
>>>>
>>>
>>>
>>
>

Re: [nug] litmus progress

From:
Michael Mathews
Date:
2011-05-02 @ 10:05
Looking at how it is implemented, I suspect--with the one exception of 
being able to write: {}.should(...)--you'd find it impossible to even 
detect that they had extended Object. Quite clever really. But yes it does
end up looking a little "magical". On the other hand, adding an interface 
that looks pretty is about all many popular frameworks and libraries have 
to offer, Gherkin for example?

I've always had a suspicion that there can be a happy marriage between 
testing and documentation. After all, if your tests are thorough and 
expressed at a high enough level, you almost have what amounts to a 
complete description of the system. And if your documentation were 
detailed enough, it could be run and proven to be true by a machine.

As a simple example imagine you wrote this:

/**
@desc Add two numbers together.
@function add
@param {number} operand1
@param {number operand2
@returns {number}
@example
var sum = add(2, 2);
assertEqual(sum, 5);
*/
function add(operand1, operand2) {
return operand1 + operand2;
}

Notice that I've written my @example in such a way that it is very 
specific to the point that it could be automatically run. Also notice that
I've (intentionally) written an error in my example that could be 
automatically detected by such an automated process. This would be useful.
Not only would it guarantee that the "add" function was documented, but it
would prove that all the examples in the docs were runnable, valid and 
correct. If you're happy with that step, it is only a little further to 
get to a unit test in the docs that could be automated.

I even went so far as to build a prototype that does run code annotations 
as tests. While it worked, the size of the "comments" began to explode to 
10 or 20 times the size of the code units they were describing. There are 
already well-argued complaints against too much "noise" introduced by 
inline docs[1] and adding inline tests only makes that problem even more 
obvious.

Which makes me think that maybe the problem could be nibbled at from the 
opposite direction: writing tests that function as documentation, which of
course is the whole point of Gherkin. Being "business readable" is it's 
raison d'être. And the same is true for should.js.

On the other other hand there is something to be said for separation of 
concerns, and maybe any tool that is excellent at documenting will 
necessarily be less than excellent at testing. These are just my various 
shifting thoughts on the matter--obviously I haven't found any happy 
solution.


[1] 
http://blog.millermedeiros.com/2011/03/inline-documentation-why-im-ditching-it/

-- 
Michael Mathews
On Monday, 2 May 2011 at 03:31, Richard Hodgson wrote: 
> Hmm...I still don't like testing libraries (like should.js) that
> extend Object - separation is a good thing.
> 
> Tom, will Litmus run in both browser and nodejs?
> 
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > I'm very interested in testing libraries that are easy to run on either:
> > node, rhino, or browser. Also I think the should.js syntax is cool. What
> > makes litmus better/different than, oh say, nodeunit, for example?
> > 
> > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
> > 
> > Have just push changes to use.no.de containing litmus docs. Not finished or
> > published to the site yet, but would still appreciate any feedback:
> > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> > into NPM. Going to wait for this to happen before integrating with litmus:
> > https://github.com/millermedeiros/js-signals/issues/20
> > https://github.com/millermedeiros/js-signals/issues/21
> > Tom
> 

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 06:41
On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:

> I'm very interested in testing libraries that are easy to run on either:
> node, rhino, or browser.
>

Me too. Well, I'm less concerned about using rhino myself, but would be
happy to support it if it wasn't to onerous.


> Also I think the should.js syntax is cool.
>

Perhaps a personal preference thing, but I don't like spelling out sentences
with chained method calls/property accesses. I love the use of well named
methods to make it clear what things are doing, but constructing the api to
make english phrase possible seems too magical.


> What makes litmus better/different than, oh say, nodeunit, for example?
>

Not used nodeunit, but it does look pretty good. Didn't really like what
they say about async tests. An explicit design goal of litmus is being able
to run tests and async tests concurrently (in as much as you ever can in
JavaScript). Doing this and statically replacing bits of API (as their
example suggests) would cause big problems, which is why (it seems to me)
their tests run in series. I'd like to get away from abusing late static
binding to do mocking, and use (instance based) dependency injection instead
- i.e. design software to be testable in expected ways, rather than doing it
by mucking about in other people's libraries.

Thoughts?

Tom


>
>
> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>
> Have just push changes to <http://use.no.de>use.no.de containing litmus
> docs. Not finished or published to the site yet, but would still appreciate
> any feedback:
>
> <https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> 
<https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> into NPM. Going to wait for this to happen before integrating with litmus:
>
> <https://github.com/millermedeiros/js-signals/issues/20>
> https://github.com/millermedeiros/js-signals/issues/20
> <https://github.com/millermedeiros/js-signals/issues/21>
> https://github.com/millermedeiros/js-signals/issues/21
>
> Tom
>
>

Re: [nug] litmus progress

From:
Michael Mathews
Date:
2011-05-02 @ 10:30
Interesting: https://github.com/nodejitsu/kyuri

The problem, for me trying to pick a testing tool for my own projects, is 
I don't see what makes Litmus a better choice than the others that are 
available (possibly a problem of the docs?). This makes me wonder if it 
isn't just a "learning exercise" by the authors, which is cool but I not a
selling point for me as a user.

JSDoc for example, differentiates itself from the other available doc 
tools as being the one that best understands the code it is documenting. 
The benefit is that you can write much shorter doc annotations and JSDoc 
can figure the rest out for you (in fact, you can use it to document code 
that has no annotation comments at all!).

What's Litmus' main selling point? (either implemented or planned?)

-- 
Michael Mathews
On Monday, 2 May 2011 at 07:41, Tom Yandell wrote: 
> 
> 
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > I'm very interested in testing libraries that are easy to run on 
either: node, rhino, or browser.
> 
> Me too. Well, I'm less concerned about using rhino myself, but would be 
happy to support it if it wasn't to onerous. 
> 
> >  Also I think the should.js syntax is cool.
> > 
> 
> 
> Perhaps a personal preference thing, but I don't like spelling out 
sentences with chained method calls/property accesses. I love the use of 
well named methods to make it clear what things are doing, but 
constructing the api to make english phrase possible seems too magical. 
> 
> > What makes litmus better/different than, oh say, nodeunit, for example?
> > 
> > 
> 
> 
> Not used nodeunit, but it does look pretty good. Didn't really like what
they say about async tests. An explicit design goal of litmus is being 
able to run tests and async tests concurrently (in as much as you ever can
in JavaScript). Doing this and statically replacing bits of API (as their 
example suggests) would cause big problems, which is why (it seems to me) 
their tests run in series. I'd like to get away from abusing late static 
binding to do mocking, and use (instance based) dependency injection 
instead - i.e. design software to be testable in expected ways, rather 
than doing it by mucking about in other people's libraries. 
> 
> Thoughts?
> 
> Tom
> 
> > 
> > 
> > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
> > 
> > > Have just push changes to use.no.de containing litmus docs. Not 
finished or published to the site yet, but would still appreciate any 
feedback:
> > > 
> > > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv 
> > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > > 
> > > Also, I've sent a pull request to Miller Medeiros for getting JS 
Signals into NPM. Going to wait for this to happen before integrating with
litmus: 
> > > 
> > > https://github.com/millermedeiros/js-signals/issues/20 
> > > https://github.com/millermedeiros/js-signals/issues/21
> > > 
> > > Tom 
> 

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 11:01
On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:

>  Interesting: https://github.com/nodejitsu/kyuri
>
>
Very interesting. Bit strange that it generates a skeleton from your
features, which you then modify. What happens if you want to modify your
features, do you modify the vows? Seems like a possible failing.


> The problem, for me trying to pick a testing tool for my own projects, is I
> don't see what makes Litmus a better choice than the others that are
> available (possibly a problem of the docs?). This makes me wonder if it
> isn't just a "learning exercise" by the authors, which is cool but I not a
> selling point for me as a user.
>

Heh, given litmus was completely undocumented until yesterday (other than
inline jsdoc), things could improve there :-) Suggestions very welcome.


>
> JSDoc for example, differentiates itself from the other available doc tools
> as being the one that best understands the code it is documenting. The
> benefit is that you can write much shorter doc annotations and JSDoc can
> figure the rest out for you (in fact, you can use it to document code that
> has no annotation comments at all!).
>
> What's Litmus' main selling point? (either implemented or planned?)
>
>
I mainly wrote litmus because no existing framework that I found had the
features I wanted and worked in the environments I wanted. There isn't
really a single distinguishing USP, but I would hope that it has/will have
the following features:

* can be run in the browser and outside the browser
* can display test output nicely in both the browser and on the command line
(both a static report and a more dynamic version while the tests run)
* can test async code
* runs as much as possible in parallel
* supports skipping assertions
* makes it easy to test exceptions
* clean design, easy and fun to hack on
* extensible - can add assertions, features, hook into events, etc.
* supports BDD (although I wasn't aware of this when I started it)
* uses libraries where appropriate (promised-io, js-signals, maybe spectrum
in the future)

Agree that it's a difficult choice. I'm going to continue using (and
developing) litmus until either it becomes really compelling, or something
else that's really compelling comes along - I hope the former as I have
significant investment litmus :-)

Tom


-- 
> Michael Mathews
>
> On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
>
>
>
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>
> I'm very interested in testing libraries that are easy to run on either:
> node, rhino, or browser.
>
>
> Me too. Well, I'm less concerned about using rhino myself, but would be
> happy to support it if it wasn't to onerous.
>
>
> Also I think the should.js syntax is cool.
>
>
> Perhaps a personal preference thing, but I don't like spelling out
> sentences with chained method calls/property accesses. I love the use of
> well named methods to make it clear what things are doing, but constructing
> the api to make english phrase possible seems too magical.
>
>
> What makes litmus better/different than, oh say, nodeunit, for example?
>
>
> Not used nodeunit, but it does look pretty good. Didn't really like what
> they say about async tests. An explicit design goal of litmus is being able
> to run tests and async tests concurrently (in as much as you ever can in
> JavaScript). Doing this and statically replacing bits of API (as their
> example suggests) would cause big problems, which is why (it seems to me)
> their tests run in series. I'd like to get away from abusing late static
> binding to do mocking, and use (instance based) dependency injection instead
> - i.e. design software to be testable in expected ways, rather than doing it
> by mucking about in other people's libraries.
>
> Thoughts?
>
> Tom
>
>
>
>
> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>
> Have just push changes to <http://use.no.de>use.no.de containing litmus
> docs. Not finished or published to the site yet, but would still appreciate
> any feedback:
>
> <https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> 
<https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> into NPM. Going to wait for this to happen before integrating with litmus:
>
> <https://github.com/millermedeiros/js-signals/issues/20>
> https://github.com/millermedeiros/js-signals/issues/20
>  <https://github.com/millermedeiros/js-signals/issues/21>
> https://github.com/millermedeiros/js-signals/issues/21
>
> Tom
>
>
>
>

Re: [nug] litmus progress

From:
Michael Mathews
Date:
2011-05-02 @ 11:13
Having fun building a testing framework is it's own reason! I'll probably 
use nodeunit for JSDoc though :)

Some features I personally would love to see in a testing framework:

* runs equally well in Rhino, Node, or browser (can be completely host 
agnostic on at least a core level).
* provides a beautiful, easy and exciting API
* supports templates or plugins for handling the various events of a test run
* trivial to set up to "watch" a folder of scripts and will automatically 
rerun itself whenever I save a change to my scripts

> runs as much as possible in parallel
Is probably useful, but unless I have many hundreds of tests (which, 
actually JSDoc 3 is approaching, at about 175 now) then this is not really
a big deal for me. Although maybe that could be the main "point" of 
Litmus: it's the fastest testing tool for node?

-- 
Michael Mathews
On Monday, 2 May 2011 at 12:01, Tom Yandell wrote: 
> On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
> > Interesting: https://github.com/nodejitsu/kyuri
> > 
> 
> Very interesting. Bit strange that it generates a skeleton from your 
features, which you then modify. What happens if you want to modify your 
features, do you modify the vows? Seems like a possible failing. 
> 
> > 
> > The problem, for me trying to pick a testing tool for my own projects,
is I don't see what makes Litmus a better choice than the others that are 
available (possibly a problem of the docs?). This makes me wonder if it 
isn't just a "learning exercise" by the authors, which is cool but I not a
selling point for me as a user.
> > 
> 
> 
> Heh, given litmus was completely undocumented until yesterday (other 
than inline jsdoc), things could improve there :-) Suggestions very 
welcome.
> 
> > 
> > JSDoc for example, differentiates itself from the other available doc 
tools as being the one that best understands the code it is documenting. 
The benefit is that you can write much shorter doc annotations and JSDoc 
can figure the rest out for you (in fact, you can use it to document code 
that has no annotation comments at all!). 
> > 
> > What's Litmus' main selling point? (either implemented or planned?)
> > 
> 
> I mainly wrote litmus because no existing framework that I found had the
features I wanted and worked in the environments I wanted. There isn't 
really a single distinguishing USP, but I would hope that it has/will have
the following features: 
> 
> * can be run in the browser and outside the browser
> * can display test output nicely in both the browser and on the command 
line (both a static report and a more dynamic version while the tests run)
> * can test async code
> * runs as much as possible in parallel
> * supports skipping assertions
> * makes it easy to test exceptions
> * clean design, easy and fun to hack on
>  * extensible - can add assertions, features, hook into events, etc.
> * supports BDD (although I wasn't aware of this when I started it)
> * uses libraries where appropriate (promised-io, js-signals, maybe 
spectrum in the future)
> 
> Agree that it's a difficult choice. I'm going to continue using (and 
developing) litmus until either it becomes really compelling, or something
else that's really compelling comes along - I hope the former as I have 
significant investment litmus :-) 
> 
> Tom
> 
> 
> > -- 
> > Michael Mathews
> > On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
> > > 
> > > 
> > > On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > > > I'm very interested in testing libraries that are easy to run on 
either: node, rhino, or browser.
> > > 
> > > Me too. Well, I'm less concerned about using rhino myself, but would
be happy to support it if it wasn't to onerous. 
> > > 
> > > >  Also I think the should.js syntax is cool.
> > > > 
> > > 
> > > 
> > > Perhaps a personal preference thing, but I don't like spelling out 
sentences with chained method calls/property accesses. I love the use of 
well named methods to make it clear what things are doing, but 
constructing the api to make english phrase possible seems too magical. 
> > > 
> > > > What makes litmus better/different than, oh say, nodeunit, for example?
> > > > 
> > > > 
> > > 
> > > 
> > > Not used nodeunit, but it does look pretty good. Didn't really like 
what they say about async tests. An explicit design goal of litmus is 
being able to run tests and async tests concurrently (in as much as you 
ever can in JavaScript). Doing this and statically replacing bits of API 
(as their example suggests) would cause big problems, which is why (it 
seems to me) their tests run in series. I'd like to get away from abusing 
late static binding to do mocking, and use (instance based) dependency 
injection instead - i.e. design software to be testable in expected ways, 
rather than doing it by mucking about in other people's libraries. 
> > > 
> > > Thoughts?
> > > 
> > > Tom
> > > 
> > > > 
> > > > 
> > > > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
> > > > 
> > > > > Have just push changes to use.no.de containing litmus docs. Not 
finished or published to the site yet, but would still appreciate any 
feedback:
> > > > > 
> > > > > https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv 
> > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > > > > 
> > > > > Also, I've sent a pull request to Miller Medeiros for getting JS
Signals into NPM. Going to wait for this to happen before integrating with
litmus: 
> > > > > 
> > > > > https://github.com/millermedeiros/js-signals/issues/20 
> > > > > https://github.com/millermedeiros/js-signals/issues/21
> > > > > 
> > > > > Tom 
> > > 
> > 
> 

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 12:16
On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:

> Having fun building a testing framework is it's own reason! I'll probably
> use nodeunit for JSDoc though :)
>
>
Fair enough, looks like a decent choice.


> Some features I personally would love to see in a testing framework:
>
> * runs equally well in Rhino, Node, or browser (can be completely host
> agnostic on at least a core level).
>

Is there a commonjs compliant module loader for rhino? I saw ringojs
supports that, but I'm more interested in something standalone.

Think I will work on browser support for litmus soon. The "out of the box"
browser support for nodeunit is interesting. It isn't like you can run the
same set of tests in the browser and command-line without extra work. This
is what I want - I want to know my modules work in both the browser and in
node.js (or other commonjs compliant environments), and only have to
maintain one set of tests.


> * provides a beautiful, easy and exciting API
>

I'd like that too, but something that allows me to get the job done would be
okay. I;d be interested in what you consider to be beautiful, easy and
exciting - gherkin is the one things that's caught my eye, which is why I'm
going to integrate some of it into litmus.


> * supports templates or plugins for handling the various events of a test
> run
>

With litmus, I've tried to keep the internal abstractions clean enough that
people should be able to hook into them. It should be possible to add extra
assertions, write formatters (both static and dynamic while the tests run)
using the (documented in jsdoc) api. This should be even better when I
replace the current event system with js-signals (it already got better when
I integrated promised-io for the runs and async stuff). I'm leaving
templates where they belong (IMO) - in a template library. I am interested
in plugin systems though - both for this and micro/proton.


> * trivial to set up to "watch" a folder of scripts and will automatically
> rerun itself whenever I save a change to my scripts
>
>
Interesting, hadn't considered this as a goal up til now. Needs further
consideration - how would a user experience test failures (does node-growl
exist)? Is this a type of immediate continuous integration system?


> runs as much as possible in parallel
>
> Is probably useful, but unless I have many hundreds of tests (which,
> actually JSDoc 3 is approaching, at about 175 now) then this is not really a
> big deal for me. Although maybe that could be the main "point" of Litmus:
> it's the fastest testing tool for node?
>
>
Speed is part of it, but what I really like is the change in development
practices that comes with the rejection of static data. Making things run in
parallel isn't a feature you can add later if code is written to (mis)use
late static binding to do mocking/stubbing I think.

Thoughts?

Tom


> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
>
> On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
>
>  Interesting: https://github.com/nodejitsu/kyuri
>
>
> Very interesting. Bit strange that it generates a skeleton from your
> features, which you then modify. What happens if you want to modify your
> features, do you modify the vows? Seems like a possible failing.
>
>
> The problem, for me trying to pick a testing tool for my own projects, is I
> don't see what makes Litmus a better choice than the others that are
> available (possibly a problem of the docs?). This makes me wonder if it
> isn't just a "learning exercise" by the authors, which is cool but I not a
> selling point for me as a user.
>
>
> Heh, given litmus was completely undocumented until yesterday (other than
> inline jsdoc), things could improve there :-) Suggestions very welcome.
>
>
>
> JSDoc for example, differentiates itself from the other available doc tools
> as being the one that best understands the code it is documenting. The
> benefit is that you can write much shorter doc annotations and JSDoc can
> figure the rest out for you (in fact, you can use it to document code that
> has no annotation comments at all!).
>
> What's Litmus' main selling point? (either implemented or planned?)
>
>
> I mainly wrote litmus because no existing framework that I found had the
> features I wanted and worked in the environments I wanted. There isn't
> really a single distinguishing USP, but I would hope that it has/will have
> the following features:
>
> * can be run in the browser and outside the browser
> * can display test output nicely in both the browser and on the command
> line (both a static report and a more dynamic version while the tests run)
> * can test async code
> * runs as much as possible in parallel
> * supports skipping assertions
> * makes it easy to test exceptions
> * clean design, easy and fun to hack on
> * extensible - can add assertions, features, hook into events, etc.
> * supports BDD (although I wasn't aware of this when I started it)
> * uses libraries where appropriate (promised-io, js-signals, maybe spectrum
> in the future)
>
> Agree that it's a difficult choice. I'm going to continue using (and
> developing) litmus until either it becomes really compelling, or something
> else that's really compelling comes along - I hope the former as I have
> significant investment litmus :-)
>
> Tom
>
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
>
>
>
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>
> I'm very interested in testing libraries that are easy to run on either:
> node, rhino, or browser.
>
>
> Me too. Well, I'm less concerned about using rhino myself, but would be
> happy to support it if it wasn't to onerous.
>
>
> Also I think the should.js syntax is cool.
>
>
> Perhaps a personal preference thing, but I don't like spelling out
> sentences with chained method calls/property accesses. I love the use of
> well named methods to make it clear what things are doing, but constructing
> the api to make english phrase possible seems too magical.
>
>
> What makes litmus better/different than, oh say, nodeunit, for example?
>
>
> Not used nodeunit, but it does look pretty good. Didn't really like what
> they say about async tests. An explicit design goal of litmus is being able
> to run tests and async tests concurrently (in as much as you ever can in
> JavaScript). Doing this and statically replacing bits of API (as their
> example suggests) would cause big problems, which is why (it seems to me)
> their tests run in series. I'd like to get away from abusing late static
> binding to do mocking, and use (instance based) dependency injection instead
> - i.e. design software to be testable in expected ways, rather than doing it
> by mucking about in other people's libraries.
>
> Thoughts?
>
> Tom
>
>
>
>
> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>
> Have just push changes to <http://use.no.de>use.no.de containing litmus
> docs. Not finished or published to the site yet, but would still appreciate
> any feedback:
>
> <https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> 
<https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> into NPM. Going to wait for this to happen before integrating with litmus:
>
> <https://github.com/millermedeiros/js-signals/issues/20>
> https://github.com/millermedeiros/js-signals/issues/20
>  <https://github.com/millermedeiros/js-signals/issues/21>
> https://github.com/millermedeiros/js-signals/issues/21
>
> Tom
>
>
>
>
>
>

Re: [nug] litmus progress

From:
Michael Mathews
Date:
2011-05-02 @ 12:33
Funny you should ask: https://github.com/visionmedia/node-growl

If there is a commonjs compliant module loader for rhino I sure as hell 
would like to know about it. I very much need that. I've had to write my 
own and it isn't perfect.

What do I consider exciting? Well, I agree that gherkin is interesting, 
but only because they tried to step outside the accepted way of doing 
things, and put human-usability first. For another example, in the 
documentation domain, I think docco[1] is pretty innovative (but to be 
honest I probably would never use it). So going in that direction in a 
creative way is what makes a product interesting, IMO. Just copying the 
same old xunit/qunit interface is conformant, but if you're going to be 
conformant with your API you damn well better be exciting in some other 
way (like "runs 100x faster!" or "integrates directly into textmate!" 
etc).

[1] http://jashkenas.github.com/docco/

-- 
Michael Mathews
On Monday, 2 May 2011 at 13:16, Tom Yandell wrote: 
> On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:
> > Having fun building a testing framework is it's own reason! I'll 
probably use nodeunit for JSDoc though :)
> > 
> 
> Fair enough, looks like a decent choice. 
> 
> > 
> > Some features I personally would love to see in a testing framework:
> > 
> > * runs equally well in Rhino, Node, or browser (can be completely host
agnostic on at least a core level).
> 
> Is there a commonjs compliant module loader for rhino? I saw ringojs 
supports that, but I'm more interested in something standalone. 
> 
> Think I will work on browser support for litmus soon. The "out of the 
box" browser support for nodeunit is interesting. It isn't like you can 
run the same set of tests in the browser and command-line without extra 
work. This is what I want - I want to know my modules work in both the 
browser and in node.js (or other commonjs compliant environments), and 
only have to maintain one set of tests. 
> 
> > * provides a beautiful, easy and exciting API
> > 
> 
> 
> I'd like that too, but something that allows me to get the job done 
would be okay. I;d be interested in what you consider to be beautiful, 
easy and exciting - gherkin is the one things that's caught my eye, which 
is why I'm going to integrate some of it into litmus. 
> 
> > * supports templates or plugins for handling the various events of a test run
> > 
> 
> 
> With litmus, I've tried to keep the internal abstractions clean enough 
that people should be able to hook into them. It should be possible to add
extra assertions, write formatters (both static and dynamic while the 
tests run) using the (documented in jsdoc) api. This should be even better
when I replace the current event system with js-signals (it already got 
better when I integrated promised-io for the runs and async stuff). I'm 
leaving templates where they belong (IMO) - in a template library. I am 
interested in plugin systems though - both for this and micro/proton. 
> 
> > * trivial to set up to "watch" a folder of scripts and will 
automatically rerun itself whenever I save a change to my scripts
> > 
> 
> Interesting, hadn't considered this as a goal up til now. Needs further 
consideration - how would a user experience test failures (does node-growl
exist)? Is this a type of immediate continuous integration system? 
> 
> > 
> > > runs as much as possible in parallel
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > Is probably useful, but unless I have many hundreds of tests (which, 
actually JSDoc 3 is approaching, at about 175 now) then this is not really
a big deal for me. Although maybe that could be the main "point" of 
Litmus: it's the fastest testing tool for node?
> > 
> 
> Speed is part of it, but what I really like is the change in development
practices that comes with the rejection of static data. Making things run 
in parallel isn't a feature you can add later if code is written to 
(mis)use late static binding to do mocking/stubbing I think. 
> 
> Thoughts?
> 
> Tom
> 
> > -- 
> > Michael Mathews
> > On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
> > > On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
> > > > Interesting: https://github.com/nodejitsu/kyuri
> > > > 
> > > 
> > >  Very interesting. Bit strange that it generates a skeleton from 
your features, which you then modify. What happens if you want to modify 
your features, do you modify the vows? Seems like a possible failing. 
> > > 
> > > > 
> > > > The problem, for me trying to pick a testing tool for my own 
projects, is I don't see what makes Litmus a better choice than the others
that are available (possibly a problem of the docs?). This makes me wonder
if it isn't just a "learning exercise" by the authors, which is cool but I
not a selling point for me as a user.
> > > > 
> > > 
> > > 
> > > Heh, given litmus was completely undocumented until yesterday (other
than inline jsdoc), things could improve there :-) Suggestions very 
welcome.
> > > 
> > > > 
> > > > JSDoc for example, differentiates itself from the other available 
doc tools as being the one that best understands the code it is 
documenting. The benefit is that you can write much shorter doc 
annotations and JSDoc can figure the rest out for you (in fact, you can 
use it to document code that has no annotation comments at all!). 
> > > > 
> > > > What's Litmus' main selling point? (either implemented or planned?)
> > > > 
> > > 
> > > I mainly wrote litmus because no existing framework that I found had
the features I wanted and worked in the environments I wanted. There isn't
really a single distinguishing USP, but I would hope that it has/will have
the following features: 
> > > 
> > > * can be run in the browser and outside the browser
> > > * can display test output nicely in both the browser and on the 
command line (both a static report and a more dynamic version while the 
tests run)
> > > * can test async code
> > > * runs as much as possible in parallel
> > > * supports skipping assertions
> > > * makes it easy to test exceptions
> > > * clean design, easy and fun to hack on
> > >  * extensible - can add assertions, features, hook into events, etc.
> > > * supports BDD (although I wasn't aware of this when I started it)
> > > * uses libraries where appropriate (promised-io, js-signals, maybe 
spectrum in the future)
> > > 
> > > Agree that it's a difficult choice. I'm going to continue using (and
developing) litmus until either it becomes really compelling, or something
else that's really compelling comes along - I hope the former as I have 
significant investment litmus :-) 
> > > 
> > > Tom
> > > 
> > > 
> > > > -- 
> > > > Michael Mathews
> > > > On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
> > > > > 
> > > > > 
> > > > > On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > > > > > I'm very interested in testing libraries that are easy to run 
on either: node, rhino, or browser.
> > > > > 
> > > > > Me too. Well, I'm less concerned about using rhino myself, but 
would be happy to support it if it wasn't to onerous. 
> > > > > 
> > > > > >  Also I think the should.js syntax is cool.
> > > > > > 
> > > > > 
> > > > > 
> > > > > Perhaps a personal preference thing, but I don't like spelling 
out sentences with chained method calls/property accesses. I love the use 
of well named methods to make it clear what things are doing, but 
constructing the api to make english phrase possible seems too magical. 
> > > > > 
> > > > > > What makes litmus better/different than, oh say, nodeunit, for
example?
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > Not used nodeunit, but it does look pretty good. Didn't really 
like what they say about async tests. An explicit design goal of litmus is
being able to run tests and async tests concurrently (in as much as you 
ever can in JavaScript). Doing this and statically replacing bits of API 
(as their example suggests) would cause big problems, which is why (it 
seems to me) their tests run in series. I'd like to get away from abusing 
late static binding to do mocking, and use (instance based) dependency 
injection instead - i.e. design software to be testable in expected ways, 
rather than doing it by mucking about in other people's libraries. 
> > > > > 
> > > > > Thoughts?
> > > > > 
> > > > > Tom
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
> > > > > > 
> > > > > > > Have just push changes to use.no.de containing litmus docs. 
Not finished or published to the site yet, but would still appreciate any 
feedback:
> > > > > > > 
> > > > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv 
> > > > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > > > > > > 
> > > > > > > Also, I've sent a pull request to Miller Medeiros for 
getting JS Signals into NPM. Going to wait for this to happen before 
integrating with litmus: 
> > > > > > > 
> > > > > > > https://github.com/millermedeiros/js-signals/issues/20 
> > > > > > > https://github.com/millermedeiros/js-signals/issues/21
> > > > > > > 
> > > > > > > Tom 
> > > > > 
> > > > 
> > > 
> > 
> 

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-02 @ 16:42
On 2 May 2011 13:33, Michael Mathews <micmath@gmail.com> wrote:

>  Funny you should ask: https://github.com/visionmedia/node-growl
>

Heh, sweet.


>
> If there is a commonjs compliant module loader for rhino I sure as hell
> would like to know about it. I very much need that. I've had to write my own
> and it isn't perfect.
>

Why not improve it, put it on github, encourage others to contribute, etc.
(I'm ignoring the fact that you hate the community :-)?


What do I consider exciting? Well, I agree that gherkin is interesting, but
> only because they tried to step outside the accepted way of doing things,
> and put human-usability first.
>

I love the way it separates the description of the functionality being
tested from the way it is being tested. This seems to be a big win  for test
maintainability (too often unit tests seem hard to maintain and brittle).
Like I said earlier, BDD is a big area where I hope to develop Litmus -
probably making use of (at least parts of) gherkin syntax and separation.
BDD derailed litmus development for quite a few months while I worked out
where I thought it might fit into the unit testing picture.


>  For another example, in the documentation domain, I think docco[1] is
> pretty innovative (but to be honest I probably would never use it).
>

Is interesting, but seems a bit of a novelty. I like to have nicely
documented code and I'd also like to be able to link api docs to the source
code being documented, but I don't think users should need to read the code
to use the API.


> So going in that direction in a creative way is what makes a product
> interesting, IMO.
>

I know what you mean, and I'm constantly looking at projects that are
interesting, but often they're interesting because you think "I could use
that idea" rather than "I could use that library" (or I do at least). In
this case, I'm not creating a testing library to be interesting - I find it
pretty hard to get excited by a testing library (using or developing). I
just want something that's solid and lets me get the job done.


> Just copying the same old xunit/qunit interface is conformant
>

Heh, I was shooting more for ease of use of Test::More than xUnit :-) Qunit
async api seems weird (similar to the way jake did his, so maybe it's me
that's weird) and a bit broken. xUnit (or Test::More) didn't have facilities
for async tests, but otherwise I quite like they way they work.


> , but if you're going to be conformant with your API you damn well better
> be exciting in some other way (like "runs 100x faster!" or "integrat es
> directly into textmate!" etc).
>

I expect that for large test suites, particularly those that perform a lot
of async operations, litmus will be a lot faster. Dunno about 100x. Expect
vim integration before textmate ;-)

Tom


> [1] http://jashkenas.github.com/docco/
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 13:16, Tom Yandell wrote:
>
> On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:
>
>  Having fun building a testing framework is it's own reason! I'll probably
> use nodeunit for JSDoc though :)
>
>
> Fair enough, looks like a decent choice.
>
>
> Some features I personally would love to see in a testing framework:
>
> * runs equally well in Rhino, Node, or browser (can be completely host
> agnostic on at least a core level).
>
>
> Is there a commonjs compliant module loader for rhino? I saw ringojs
> supports that, but I'm more interested in something standalone.
>
> Think I will work on browser support for litmus soon. The "out of the box"
> browser support for nodeunit is interesting. It isn't like you can run the
> same set of tests in the browser and command-line without extra work. This
> is what I want - I want to know my modules work in both the browser and in
> node.js (or other commonjs compliant environments), and only have to
> maintain one set of tests.
>
>
> * provides a beautiful, easy and exciting API
>
>
> I'd like that too, but something that allows me to get the job done would
> be okay. I;d be interested in what you consider to be beautiful, easy and
> exciting - gherkin is the one things that's caught my eye, which is why I'm
> going to integrate some of it into litmus.
>
>
> * supports templates or plugins for handling the various events of a test
> run
>
>
> With litmus, I've tried to keep the internal abstractions clean enough that
> people should be able to hook into them. It should be possible to add extra
> assertions, write formatters (both static and dynamic while the tests run)
> using the (documented in jsdoc) api. This should be even better when I
> replace the current event system with js-signals (it already got better when
> I integrated promised-io for the runs and async stuff). I'm leaving
> templates where they belong (IMO) - in a template library. I am interested
> in plugin systems though - both for this and micro/proton.
>
>
> * trivial to set up to "watch" a folder of scripts and will automatically
> rerun itself whenever I save a change to my scripts
>
>
> Interesting, hadn't considered this as a goal up til now. Needs further
> consideration - how would a user experience test failures (does node-growl
> exist)? Is this a type of immediate continuous integration system?
>
>
> runs as much as possible in parallel
>
> Is probably useful, but unless I have many hundreds of tests (which,
> actually JSDoc 3 is approaching, at about 175 now) then this is not really a
> big deal for me. Although maybe that could be the main "point" of Litmus:
> it's the fastest testing tool for node?
>
>
> Speed is part of it, but what I really like is the change in development
> practices that comes with the rejection of static data. Making things run in
> parallel isn't a feature you can add later if code is written to (mis)use
> late static binding to do mocking/stubbing I think.
>
> Thoughts?
>
> Tom
>
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
>
> On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
>
>  Interesting: https://github.com/nodejitsu/kyuri
>
>
> Very interesting. Bit strange that it generates a skeleton from your
> features, which you then modify. What happens if you want to modify your
> features, do you modify the vows? Seems like a possible failing.
>
>
> The problem, for me trying to pick a testing tool for my own projects, is I
> don't see what makes Litmus a better choice than the others that are
> available (possibly a problem of the docs?). This makes me wonder if it
> isn't just a "learning exercise" by the authors, which is cool but I not a
> selling point for me as a user.
>
>
> Heh, given litmus was completely undocumented until yesterday (other than
> inline jsdoc), things could improve there :-) Suggestions very welcome.
>
>
>
> JSDoc for example, differentiates itself from the other available doc tools
> as being the one that best understands the code it is documenting. The
> benefit is that you can write much shorter doc annotations and JSDoc can
> figure the rest out for you (in fact, you can use it to document code that
> has no annotation comments at all!).
>
> What's Litmus' main selling point? (either implemented or planned?)
>
>
> I mainly wrote litmus because no existing framework that I found had the
> features I wanted and worked in the environments I wanted. There isn't
> really a single distinguishing USP, but I would hope that it has/will have
> the following features:
>
> * can be run in the browser and outside the browser
> * can display test output nicely in both the browser and on the command
> line (both a static report and a more dynamic version while the tests run)
> * can test async code
> * runs as much as possible in parallel
> * supports skipping assertions
> * makes it easy to test exceptions
> * clean design, easy and fun to hack on
> * extensible - can add assertions, features, hook into events, etc.
> * supports BDD (although I wasn't aware of this when I started it)
> * uses libraries where appropriate (promised-io, js-signals, maybe spectrum
> in the future)
>
> Agree that it's a difficult choice. I'm going to continue using (and
> developing) litmus until either it becomes really compelling, or something
> else that's really compelling comes along - I hope the former as I have
> significant investment litmus :-)
>
> Tom
>
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
>
>
>
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>
> I'm very interested in testing libraries that are easy to run on either:
> node, rhino, or browser.
>
>
> Me too. Well, I'm less concerned about using rhino myself, but would be
> happy to support it if it wasn't to onerous.
>
>
> Also I think the should.js syntax is cool.
>
>
> Perhaps a personal preference thing, but I don't like spelling out
> sentences with chained method calls/property accesses. I love the use of
> well named methods to make it clear what things are doing, but constructing
> the api to make english phrase possible seems too magical.
>
>
> What makes litmus better/different than, oh say, nodeunit, for example?
>
>
> Not used nodeunit, but it does look pretty good. Didn't really like what
> they say about async tests. An explicit design goal of litmus is being able
> to run tests and async tests concurrently (in as much as you ever can in
> JavaScript). Doing this and statically replacing bits of API (as their
> example suggests) would cause big problems, which is why (it seems to me)
> their tests run in series. I'd like to get away from abusing late static
> binding to do mocking, and use (instance based) dependency injection instead
> - i.e. design software to be testable in expected ways, rather than doing it
> by mucking about in other people's libraries.
>
> Thoughts?
>
> Tom
>
>
>
>
> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>
> Have just push changes to <http://use.no.de>use.no.de containing litmus
> docs. Not finished or published to the site yet, but would still appreciate
> any feedback:
>
> <https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> 
<https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> into NPM. Going to wait for this to happen before integrating with litmus:
>
> <https://github.com/millermedeiros/js-signals/issues/20>
> https://github.com/millermedeiros/js-signals/issues/20
>  <https://github.com/millermedeiros/js-signals/issues/21>
> https://github.com/millermedeiros/js-signals/issues/21
>
> Tom
>
>
>
>
>
>
>
>

Re: [nug] litmus progress

From:
Michael Mathews
Date:
2011-05-02 @ 17:35

-- 
Michael Mathews
On Monday, 2 May 2011 at 17:42, Tom Yandell wrote: 
> On 2 May 2011 13:33, Michael Mathews <micmath@gmail.com> wrote:
> > Funny you should ask: https://github.com/visionmedia/node-growl
> 
> Heh, sweet. 
> 
> > 
> > If there is a commonjs compliant module loader for rhino I sure as 
hell would like to know about it. I very much need that. I've had to write
my own and it isn't perfect. 
> 
> Why not improve it, put it on github, encourage others to contribute, 
etc. (I'm ignoring the fact that you hate the community :-)?
> 
> 
> 
> 


My gawd, you are cynical: https://github.com/micmath/Rhino-Require
I look forward to your contributions.


> > What do I consider exciting? Well, I agree that gherkin is 
interesting, but only because they tried to step outside the accepted way 
of doing things, and put human-usability first.
> 
> I love the way it separates the description of the functionality being 
tested from the way it is being tested. This seems to be a big win for 
test maintainability (too often unit tests seem hard to maintain and 
brittle). Like I said earlier, BDD is a big area where I hope to develop 
Litmus - probably making use of (at least parts of) gherkin syntax and 
separation. BDD derailed litmus development for quite a few months while I
worked out where I thought it might fit into the unit testing picture. 
> 
> > For another example, in the documentation domain, I think docco[1] is 
pretty innovative (but to be honest I probably would never use it). 
> > 
> 
> 
> Is interesting, but seems a bit of a novelty. I like to have nicely 
documented code and I'd also like to be able to link api docs to the 
source code being documented, but I don't think users should need to read 
the code to use the API. 
> 
> > So going in that direction in a creative way is what makes a product 
interesting, IMO.
> > 
> > 
> 
> 
> I know what you mean, and I'm constantly looking at projects that are 
interesting, but often they're interesting because you think "I could use 
that idea" rather than "I could use that library" (or I do at least). In 
this case, I'm not creating a testing library to be interesting - I find 
it pretty hard to get excited by a testing library (using or developing). 
I just want something that's solid and lets me get the job done. 
> 
> > Just copying the same old xunit/qunit interface is conformant
> > 
> 
> 
> Heh, I was shooting more for ease of use of Test::More than xUnit :-) 
Qunit async api seems weird (similar to the way jake did his, so maybe 
it's me that's weird) and a bit broken. xUnit (or Test::More) didn't have 
facilities for async tests, but otherwise I quite like they way they work.

> 
> > , but if you're going to be conformant with your API you damn well 
better be exciting in some other way (like "runs 100x faster!" or 
"integrat es directly into textmate!" etc).
> > 
> 
> 
> I expect that for large test suites, particularly those that perform a 
lot of async operations, litmus will be a lot faster. Dunno about 100x. 
Expect vim integration before textmate ;-) 
> 
> Tom
> 
> > 
> > [1] http://jashkenas.github.com/docco/
> > 
> > -- 
> > Michael Mathews
> > On Monday, 2 May 2011 at 13:16, Tom Yandell wrote:
> > > On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:
> > > > Having fun building a testing framework is it's own reason! I'll 
probably use nodeunit for JSDoc though :)
> > > > 
> > > 
> > >  Fair enough, looks like a decent choice. 
> > > 
> > > > 
> > > > Some features I personally would love to see in a testing framework:
> > > > 
> > > > * runs equally well in Rhino, Node, or browser (can be completely 
host agnostic on at least a core level).
> > > 
> > > Is there a commonjs compliant module loader for rhino? I saw ringojs
supports that, but I'm more interested in something standalone. 
> > > 
> > > Think I will work on browser support for litmus soon. The "out of 
the box" browser support for nodeunit is interesting. It isn't like you 
can run the same set of tests in the browser and command-line without 
extra work. This is what I want - I want to know my modules work in both 
the browser and in node.js (or other commonjs compliant environments), and
only have to maintain one set of tests. 
> > > 
> > > > * provides a beautiful, easy and exciting API
> > > > 
> > > 
> > > 
> > > I'd like that too, but something that allows me to get the job done 
would be okay. I;d be interested in what you consider to be beautiful, 
easy and exciting - gherkin is the one things that's caught my eye, which 
is why I'm going to integrate some of it into litmus. 
> > > 
> > > > * supports templates or plugins for handling the various events of
a test run
> > > > 
> > > 
> > > 
> > > With litmus, I've tried to keep the internal abstractions clean 
enough that people should be able to hook into them. It should be possible
to add extra assertions, write formatters (both static and dynamic while 
the tests run) using the (documented in jsdoc) api. This should be even 
better when I replace the current event system with js-signals (it already
got better when I integrated promised-io for the runs and async stuff). 
I'm leaving templates where they belong (IMO) - in a template library. I 
am interested in plugin systems though - both for this and micro/proton. 
> > > 
> > > > * trivial to set up to "watch" a folder of scripts and will 
automatically rerun itself whenever I save a change to my scripts
> > > > 
> > > 
> > > Interesting, hadn't considered this as a goal up til now. Needs 
further consideration - how would a user experience test failures (does 
node-growl exist)? Is this a type of immediate continuous integration 
system? 
> > > 
> > > > 
> > > > > runs as much as possible in parallel
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > Is probably useful, but unless I have many hundreds of tests 
(which, actually JSDoc 3 is approaching, at about 175 now) then this is 
not really a big deal for me. Although maybe that could be the main 
"point" of Litmus: it's the fastest testing tool for node?
> > > > 
> > > 
> > > Speed is part of it, but what I really like is the change in 
development practices that comes with the rejection of static data. Making
things run in parallel isn't a feature you can add later if code is 
written to (mis)use late static binding to do mocking/stubbing I think. 
> > > 
> > > Thoughts?
> > > 
> > > Tom
> > > 
> > > > -- 
> > > > Michael Mathews
> > > > On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
> > > > > On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
> > > > > > Interesting: https://github.com/nodejitsu/kyuri
> > > > > > 
> > > > > 
> > > > >  Very interesting. Bit strange that it generates a skeleton from
your features, which you then modify. What happens if you want to modify 
your features, do you modify the vows? Seems like a possible failing. 
> > > > > 
> > > > > > 
> > > > > > The problem, for me trying to pick a testing tool for my own 
projects, is I don't see what makes Litmus a better choice than the others
that are available (possibly a problem of the docs?). This makes me wonder
if it isn't just a "learning exercise" by the authors, which is cool but I
not a selling point for me as a user.
> > > > > > 
> > > > > 
> > > > > 
> > > > > Heh, given litmus was completely undocumented until yesterday 
(other than inline jsdoc), things could improve there :-) Suggestions very
welcome.
> > > > > 
> > > > > > 
> > > > > > JSDoc for example, differentiates itself from the other 
available doc tools as being the one that best understands the code it is 
documenting. The benefit is that you can write much shorter doc 
annotations and JSDoc can figure the rest out for you (in fact, you can 
use it to document code that has no annotation comments at all!). 
> > > > > > 
> > > > > > What's Litmus' main selling point? (either implemented or planned?)
> > > > > > 
> > > > > 
> > > > > I mainly wrote litmus because no existing framework that I found
had the features I wanted and worked in the environments I wanted. There 
isn't really a single distinguishing USP, but I would hope that it 
has/will have the following features: 
> > > > > 
> > > > > * can be run in the browser and outside the browser
> > > > > * can display test output nicely in both the browser and on the 
command line (both a static report and a more dynamic version while the 
tests run)
> > > > > * can test async code
> > > > > * runs as much as possible in parallel
> > > > > * supports skipping assertions
> > > > > * makes it easy to test exceptions
> > > > > * clean design, easy and fun to hack on
> > > > >  * extensible - can add assertions, features, hook into events, etc.
> > > > > * supports BDD (although I wasn't aware of this when I started it)
> > > > > * uses libraries where appropriate (promised-io, js-signals, 
maybe spectrum in the future)
> > > > > 
> > > > > Agree that it's a difficult choice. I'm going to continue using 
(and developing) litmus until either it becomes really compelling, or 
something else that's really compelling comes along - I hope the former as
I have significant investment litmus :-) 
> > > > > 
> > > > > Tom
> > > > > 
> > > > > 
> > > > > > -- 
> > > > > > Michael Mathews
> > > > > > On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > > > > > > > I'm very interested in testing libraries that are easy to 
run on either: node, rhino, or browser.
> > > > > > > 
> > > > > > > Me too. Well, I'm less concerned about using rhino myself, 
but would be happy to support it if it wasn't to onerous. 
> > > > > > > 
> > > > > > > >  Also I think the should.js syntax is cool.
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Perhaps a personal preference thing, but I don't like 
spelling out sentences with chained method calls/property accesses. I love
the use of well named methods to make it clear what things are doing, but 
constructing the api to make english phrase possible seems too magical. 
> > > > > > > 
> > > > > > > > What makes litmus better/different than, oh say, nodeunit,
for example?
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Not used nodeunit, but it does look pretty good. Didn't 
really like what they say about async tests. An explicit design goal of 
litmus is being able to run tests and async tests concurrently (in as much
as you ever can in JavaScript). Doing this and statically replacing bits 
of API (as their example suggests) would cause big problems, which is why 
(it seems to me) their tests run in series. I'd like to get away from 
abusing late static binding to do mocking, and use (instance based) 
dependency injection instead - i.e. design software to be testable in 
expected ways, rather than doing it by mucking about in other people's 
libraries. 
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > > 
> > > > > > > Tom
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
> > > > > > > > 
> > > > > > > > > Have just push changes to use.no.de containing litmus 
docs. Not finished or published to the site yet, but would still 
appreciate any feedback:
> > > > > > > > > 
> > > > > > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv 
> > > > > > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > > > > > > > > 
> > > > > > > > > Also, I've sent a pull request to Miller Medeiros for 
getting JS Signals into NPM. Going to wait for this to happen before 
integrating with litmus: 
> > > > > > > > > 
> > > > > > > > > https://github.com/millermedeiros/js-signals/issues/20 
> > > > > > > > > https://github.com/millermedeiros/js-signals/issues/21
> > > > > > > > > 
> > > > > > > > > Tom 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Re: [nug] litmus progress

From:
Tom Yandell
Date:
2011-05-03 @ 06:11
Cool, what shortcomings does it have? Thought about a testing framework? :-p

In other news, js-signals is now in NPM :-) The package name is "signals":

http://search.npmjs.org/#/signals

Maybe what's needed is an R(hino)PM?

Tom

On 2 May 2011 18:35, Michael Mathews <micmath@gmail.com> wrote:

>
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 17:42, Tom Yandell wrote:
>
> On 2 May 2011 13:33, Michael Mathews <micmath@gmail.com> wrote:
>
>  Funny you should ask: https://github.com/visionmedia/node-growl
>
>
> Heh, sweet.
>
>
>
> If there is a commonjs compliant module loader for rhino I sure as hell
> would like to know about it. I very much need that. I've had to write my own
> and it isn't perfect.
>
>
> Why not improve it, put it on github, encourage others to contribute, etc.
> (I'm ignoring the fact that you hate the community :-)?
>
>
>
> My gawd, you are cynical: https://github.com/micmath/Rhino-Require
> I look forward to your contributions.
>
>
>
>
>  What do I consider exciting? Well, I agree that gherkin is interesting,
> but only because they tried to step outside the accepted way of doing
> things, and put human-usability first.
>
>
> I love the way it separates the description of the functionality being
> tested from the way it is being tested. This seems to be a big win  for test
> maintainability (too often unit tests seem hard to maintain and brittle).
> Like I said earlier, BDD is a big area where I hope to develop Litmus -
> probably making use of (at least parts of) gherkin syntax and separation.
> BDD derailed litmus development for quite a few months while I worked out
> where I thought it might fit into the unit testing picture.
>
>
>  For another example, in the documentation domain, I think docco[1] is
> pretty innovative (but to be honest I probably would never use it).
>
>
> Is interesting, but seems a bit of a novelty. I like to have nicely
> documented code and I'd also like to be able to link api docs to the source
> code being documented, but I don't think users should need to read the code
> to use the API.
>
>
> So going in that direction in a creative way is what makes a product
> interesting, IMO.
>
>
> I know what you mean, and I'm constantly looking at projects that are
> interesting, but often they're interesting because you think "I could use
> that idea" rather than "I could use that library" (or I do at least). In
> this case, I'm not creating a testing library to be interesting - I find it
> pretty hard to get excited by a testing library (using or developing). I
> just want something that's solid and lets me get the job done.
>
>
> Just copying the same old xunit/qunit interface is conformant
>
>
> Heh, I was shooting more for ease of use of Test::More than xUnit :-) Qunit
> async api seems weird (similar to the way jake did his, so maybe it's me
> that's weird) and a bit broken. xUnit (or Test::More) didn't have facilities
> for async tests, but otherwise I quite like they way they work.
>
>
> , but if you're going to be conformant with your API you damn well better
> be exciting in some other way (like "runs 100x faster!" or "integrat es
> directly into textmate!" etc).
>
>
> I expect that for large test suites, particularly those that perform a lot
> of async operations, litmus will be a lot faster. Dunno about 100x. Expect
> vim integration before textmate ;-)
>
> Tom
>
>
> [1] http://jashkenas.github.com/docco/
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 13:16, Tom Yandell wrote:
>
> On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:
>
>  Having fun building a testing framework is it's own reason! I'll probably
> use nodeunit for JSDoc though :)
>
>
> Fair enough, looks like a decent choice.
>
>
> Some features I personally would love to see in a testing framework:
>
> * runs equally well in Rhino, Node, or browser (can be completely host
> agnostic on at least a core level).
>
>
> Is there a commonjs compliant module loader for rhino? I saw ringojs
> supports that, but I'm more interested in something standalone.
>
> Think I will work on browser support for litmus soon. The "out of the box"
> browser support for nodeunit is interesting. It isn't like you can run the
> same set of tests in the browser and command-line without extra work. This
> is what I want - I want to know my modules work in both the browser and in
> node.js (or other commonjs compliant environments), and only have to
> maintain one set of tests.
>
>
> * provides a beautiful, easy and exciting API
>
>
> I'd like that too, but something that allows me to get the job done would
> be okay. I;d be interested in what you consider to be beautiful, easy and
> exciting - gherkin is the one things that's caught my eye, which is why I'm
> going to integrate some of it into litmus.
>
>
> * supports templates or plugins for handling the various events of a test
> run
>
>
> With litmus, I've tried to keep the internal abstractions clean enough that
> people should be able to hook into them. It should be possible to add extra
> assertions, write formatters (both static and dynamic while the tests run)
> using the (documented in jsdoc) api. This should be even better when I
> replace the current event system with js-signals (it already got better when
> I integrated promised-io for the runs and async stuff). I'm leaving
> templates where they belong (IMO) - in a template library. I am interested
> in plugin systems though - both for this and micro/proton.
>
>
> * trivial to set up to "watch" a folder of scripts and will automatically
> rerun itself whenever I save a change to my scripts
>
>
> Interesting, hadn't considered this as a goal up til now. Needs further
> consideration - how would a user experience test failures (does node-growl
> exist)? Is this a type of immediate continuous integration system?
>
>
> runs as much as possible in parallel
>
> Is probably useful, but unless I have many hundreds of tests (which,
> actually JSDoc 3 is approaching, at about 175 now) then this is not really a
> big deal for me. Although maybe that could be the main "point" of Litmus:
> it's the fastest testing tool for node?
>
>
> Speed is part of it, but what I really like is the change in development
> practices that comes with the rejection of static data. Making things run in
> parallel isn't a feature you can add later if code is written to (mis)use
> late static binding to do mocking/stubbing I think.
>
> Thoughts?
>
> Tom
>
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
>
> On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
>
>  Interesting: https://github.com/nodejitsu/kyuri
>
>
> Very interesting. Bit strange that it generates a skeleton from your
> features, which you then modify. What happens if you want to modify your
> features, do you modify the vows? Seems like a possible failing.
>
>
> The problem, for me trying to pick a testing tool for my own projects, is I
> don't see what makes Litmus a better choice than the others that are
> available (possibly a problem of the docs?). This makes me wonder if it
> isn't just a "learning exercise" by the authors, which is cool but I not a
> selling point for me as a user.
>
>
> Heh, given litmus was completely undocumented until yesterday (other than
> inline jsdoc), things could improve there :-) Suggestions very welcome.
>
>
>
> JSDoc for example, differentiates itself from the other available doc tools
> as being the one that best understands the code it is documenting. The
> benefit is that you can write much shorter doc annotations and JSDoc can
> figure the rest out for you (in fact, you can use it to document code that
> has no annotation comments at all!).
>
> What's Litmus' main selling point? (either implemented or planned?)
>
>
> I mainly wrote litmus because no existing framework that I found had the
> features I wanted and worked in the environments I wanted. There isn't
> really a single distinguishing USP, but I would hope that it has/will have
> the following features:
>
> * can be run in the browser and outside the browser
> * can display test output nicely in both the browser and on the command
> line (both a static report and a more dynamic version while the tests run)
> * can test async code
> * runs as much as possible in parallel
> * supports skipping assertions
> * makes it easy to test exceptions
> * clean design, easy and fun to hack on
> * extensible - can add assertions, features, hook into events, etc.
> * supports BDD (although I wasn't aware of this when I started it)
> * uses libraries where appropriate (promised-io, js-signals, maybe spectrum
> in the future)
>
> Agree that it's a difficult choice. I'm going to continue using (and
> developing) litmus until either it becomes really compelling, or something
> else that's really compelling comes along - I hope the former as I have
> significant investment litmus :-)
>
> Tom
>
>
> --
> Michael Mathews
>
> On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
>
>
>
> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>
> I'm very interested in testing libraries that are easy to run on either:
> node, rhino, or browser.
>
>
> Me too. Well, I'm less concerned about using rhino myself, but would be
> happy to support it if it wasn't to onerous.
>
>
> Also I think the should.js syntax is cool.
>
>
> Perhaps a personal preference thing, but I don't like spelling out
> sentences with chained method calls/property accesses. I love the use of
> well named methods to make it clear what things are doing, but constructing
> the api to make english phrase possible seems too magical.
>
>
> What makes litmus better/different than, oh say, nodeunit, for example?
>
>
> Not used nodeunit, but it does look pretty good. Didn't really like what
> they say about async tests. An explicit design goal of litmus is being able
> to run tests and async tests concurrently (in as much as you ever can in
> JavaScript). Doing this and statically replacing bits of API (as their
> example suggests) would cause big problems, which is why (it seems to me)
> their tests run in series. I'd like to get away from abusing late static
> binding to do mocking, and use (instance based) dependency injection instead
> - i.e. design software to be testable in expected ways, rather than doing it
> by mucking about in other people's libraries.
>
> Thoughts?
>
> Tom
>
>
>
>
> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>
> Have just push changes to <http://use.no.de>use.no.de containing litmus
> docs. Not finished or published to the site yet, but would still appreciate
> any feedback:
>
> <https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
> 
<https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv>
> https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>
> Also, I've sent a pull request to Miller Medeiros for getting JS Signals
> into NPM. Going to wait for this to happen before integrating with litmus:
>
> <https://github.com/millermedeiros/js-signals/issues/20>
> https://github.com/millermedeiros/js-signals/issues/20
>  <https://github.com/millermedeiros/js-signals/issues/21>
> https://github.com/millermedeiros/js-signals/issues/21
>
> Tom
>
>
>
>
>
>
>
>
>
>

Re: [nug] litmus progress

From:
Michael
Date:
2011-05-03 @ 06:37
Shortcomings are that it doesn't yet have encoded in it all the rules for 
resolving the location of the required module. To do that properly I would
need to add the folder searching algorithm, including reading any 
package.json files to discover the location of main.

And yes, it really needs some test love.

On 3 May 2011, at 07:11, Tom Yandell <tom@yandell.me.uk> wrote:

> Cool, what shortcomings does it have? Thought about a testing framework? :-p
> 
> In other news, js-signals is now in NPM :-) The package name is "signals":
> 
> http://search.npmjs.org/#/signals
> 
> Maybe what's needed is an R(hino)PM?
> 
> Tom
> 
> On 2 May 2011 18:35, Michael Mathews <micmath@gmail.com> wrote:
> 
> 
> -- 
> Michael Mathews
> On Monday, 2 May 2011 at 17:42, Tom Yandell wrote:
> 
>> On 2 May 2011 13:33, Michael Mathews <micmath@gmail.com> wrote:
>>> Funny you should ask: https://github.com/visionmedia/node-growl
>> 
>> Heh, sweet.
>>  
>> 
>> If there is a commonjs compliant module loader for rhino I sure as hell
would like to know about it. I very much need that. I've had to write my 
own and it isn't perfect.
>> 
>> Why not improve it, put it on github, encourage others to contribute, 
etc. (I'm ignoring the fact that you hate the community :-)?
>>  
> 
> My gawd, you are cynical: https://github.com/micmath/Rhino-Require
> I look forward to your contributions.
> 
>  
>> 
>>> What do I consider exciting? Well, I agree that gherkin is 
interesting, but only because they tried to step outside the accepted way 
of doing things, and put human-usability first.
>> 
>> I love the way it separates the description of the functionality being 
tested from the way it is being tested. This seems to be a big win  for 
test maintainability (too often unit tests seem hard to maintain and 
brittle). Like I said earlier, BDD is a big area where I hope to develop 
Litmus - probably making use of (at least parts of) gherkin syntax and 
separation. BDD derailed litmus development for quite a few months while I
worked out where I thought it might fit into the unit testing picture.
>>  
>>  For another example, in the documentation domain, I think docco[1] is 
pretty innovative (but to be honest I probably would never use it). 
>> 
>> Is interesting, but seems a bit of a novelty. I like to have nicely 
documented code and I'd also like to be able to link api docs to the 
source code being documented, but I don't think users should need to read 
the code to use the API.
>>  
>>> So going in that direction in a creative way is what makes a product 
interesting, IMO.
>> 
>> I know what you mean, and I'm constantly looking at projects that are 
interesting, but often they're interesting because you think "I could use 
that idea" rather than "I could use that library" (or I do at least). In 
this case, I'm not creating a testing library to be interesting - I find 
it pretty hard to get excited by a testing library (using or developing). 
I just want something that's solid and lets me get the job done.
>>  
>> Just copying the same old xunit/qunit interface is conformant
>> 
>> Heh, I was shooting more for ease of use of Test::More than xUnit :-) 
Qunit async api seems weird (similar to the way jake did his, so maybe 
it's me that's weird) and a bit broken. xUnit (or Test::More) didn't have 
facilities for async tests, but otherwise I quite like they way they work.

>>  
>> , but if you're going to be conformant with your API you damn well 
better be exciting in some other way (like "runs 100x faster!" or 
"integrat es directly into textmate!" etc).
>> 
>> I expect that for large test suites, particularly those that perform a 
lot of async operations, litmus will be a lot faster. Dunno about 100x. 
Expect vim integration before textmate ;-)
>> 
>> Tom
>>  
>> [1] http://jashkenas.github.com/docco/
>> 
>> -- 
>> Michael Mathews
>> On Monday, 2 May 2011 at 13:16, Tom Yandell wrote:
>> 
>>> On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:
>>>> Having fun building a testing framework is it's own reason! I'll 
probably use nodeunit for JSDoc though :)
>>>> 
>>> 
>>> Fair enough, looks like a decent choice.
>>>  
>>> Some features I personally would love to see in a testing framework:
>>> 
>>> * runs equally well in Rhino, Node, or browser (can be completely host
agnostic on at least a core level).
>>> 
>>> Is there a commonjs compliant module loader for rhino? I saw ringojs 
supports that, but I'm more interested in something standalone.
>>> 
>>> Think I will work on browser support for litmus soon. The "out of the 
box" browser support for nodeunit is interesting. It isn't like you can 
run the same set of tests in the browser and command-line without extra 
work. This is what I want - I want to know my modules work in both the 
browser and in node.js (or other commonjs compliant environments), and 
only have to maintain one set of tests.
>>>  
>>> * provides a beautiful, easy and exciting API
>>> 
>>> I'd like that too, but something that allows me to get the job done 
would be okay. I;d be interested in what you consider to be beautiful, 
easy and exciting - gherkin is the one things that's caught my eye, which 
is why I'm going to integrate some of it into litmus.
>>>  
>>> * supports templates or plugins for handling the various events of a test run
>>> 
>>> With litmus, I've tried to keep the internal abstractions clean enough
that people should be able to hook into them. It should be possible to add
extra assertions, write formatters (both static and dynamic while the 
tests run) using the (documented in jsdoc) api. This should be even better
when I replace the current event system with js-signals (it already got 
better when I integrated promised-io for the runs and async stuff). I'm 
leaving templates where they belong (IMO) - in a template library. I am 
interested in plugin systems though - both for this and micro/proton.
>>>  
>>> * trivial to set up to "watch" a folder of scripts and will 
automatically rerun itself whenever I save a change to my scripts
>>> 
>>> 
>>> Interesting, hadn't considered this as a goal up til now. Needs 
further consideration - how would a user experience test failures (does 
node-growl exist)? Is this a type of immediate continuous integration 
system?
>>>  
>>>> runs as much as possible in parallel
>>> 
>>> Is probably useful, but unless I have many hundreds of tests (which, 
actually JSDoc 3 is approaching, at about 175 now) then this is not really
a big deal for me. Although maybe that could be the main "point" of 
Litmus: it's the fastest testing tool for node?
>>> 
>>> 
>>> Speed is part of it, but what I really like is the change in 
development practices that comes with the rejection of static data. Making
things run in parallel isn't a feature you can add later if code is 
written to (mis)use late static binding to do mocking/stubbing I think.
>>> 
>>> Thoughts?
>>> 
>>> Tom
>>>  
>>> -- 
>>> Michael Mathews
>>> On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
>>> 
>>>> On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
>>>>> Interesting: https://github.com/nodejitsu/kyuri
>>>>> 
>>>> 
>>>> Very interesting. Bit strange that it generates a skeleton from your 
features, which you then modify. What happens if you want to modify your 
features, do you modify the vows? Seems like a possible failing.
>>>>  
>>>> The problem, for me trying to pick a testing tool for my own 
projects, is I don't see what makes Litmus a better choice than the others
that are available (possibly a problem of the docs?). This makes me wonder
if it isn't just a "learning exercise" by the authors, which is cool but I
not a selling point for me as a user.
>>>> 
>>>> Heh, given litmus was completely undocumented until yesterday (other 
than inline jsdoc), things could improve there :-) Suggestions very 
welcome.
>>>>  
>>>>> 
>>>>> JSDoc for example, differentiates itself from the other available 
doc tools as being the one that best understands the code it is 
documenting. The benefit is that you can write much shorter doc 
annotations and JSDoc can figure the rest out for you (in fact, you can 
use it to document code that has no annotation comments at all!).
>>>>> 
>>>>> What's Litmus' main selling point? (either implemented or planned?)
>>>>> 
>>>> 
>>>> I mainly wrote litmus because no existing framework that I found had 
the features I wanted and worked in the environments I wanted. There isn't
really a single distinguishing USP, but I would hope that it has/will have
the following features:
>>>> 
>>>> * can be run in the browser and outside the browser
>>>> * can display test output nicely in both the browser and on the 
command line (both a static report and a more dynamic version while the 
tests run)
>>>> * can test async code
>>>> * runs as much as possible in parallel
>>>> * supports skipping assertions
>>>> * makes it easy to test exceptions
>>>> * clean design, easy and fun to hack on
>>>> * extensible - can add assertions, features, hook into events, etc.
>>>> * supports BDD (although I wasn't aware of this when I started it)
>>>> * uses libraries where appropriate (promised-io, js-signals, maybe 
spectrum in the future)
>>>> 
>>>> Agree that it's a difficult choice. I'm going to continue using (and 
developing) litmus until either it becomes really compelling, or something
else that's really compelling comes along - I hope the former as I have 
significant investment litmus :-)
>>>> 
>>>> Tom
>>>> 
>>>> 
>>>> -- 
>>>> Michael Mathews
>>>> On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
>>>>>> I'm very interested in testing libraries that are easy to run on 
either: node, rhino, or browser.
>>>>> 
>>>>> Me too. Well, I'm less concerned about using rhino myself, but would
be happy to support it if it wasn't to onerous.
>>>>>  
>>>>> Also I think the should.js syntax is cool.
>>>>> 
>>>>> Perhaps a personal preference thing, but I don't like spelling out 
sentences with chained method calls/property accesses. I love the use of 
well named methods to make it clear what things are doing, but 
constructing the api to make english phrase possible seems too magical.
>>>>>  
>>>>>> What makes litmus better/different than, oh say, nodeunit, for example?
>>>>> 
>>>>> Not used nodeunit, but it does look pretty good. Didn't really like 
what they say about async tests. An explicit design goal of litmus is 
being able to run tests and async tests concurrently (in as much as you 
ever can in JavaScript). Doing this and statically replacing bits of API 
(as their example suggests) would cause big problems, which is why (it 
seems to me) their tests run in series. I'd like to get away from abusing 
late static binding to do mocking, and use (instance based) dependency 
injection instead - i.e. design software to be testable in expected ways, 
rather than doing it by mucking about in other people's libraries.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Tom
>>>>>  
>>>>> 
>>>>> 
>>>>> On 1 May 2011, at 18:21, Tom Yandell <tom@yandell.me.uk> wrote:
>>>>> 
>>>>>> Have just push changes to use.no.de containing litmus docs. Not 
finished or published to the site yet, but would still appreciate any 
feedback:
>>>>>> 
>>>>>> https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv
>>>>>> 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
>>>>>> 
>>>>>> Also, I've sent a pull request to Miller Medeiros for getting JS 
Signals into NPM. Going to wait for this to happen before integrating with
litmus:
>>>>>> 
>>>>>> https://github.com/millermedeiros/js-signals/issues/20
>>>>>> https://github.com/millermedeiros/js-signals/issues/21
>>>>>> 
>>>>>> Tom
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [nug] litmus progress

From:
Michael Mathews
Date:
2011-05-03 @ 07:04
Luckily, there seems to be very explicit documentation of the algorithm 
nodejs uses. Can't fault nodejs for its docs!

http://nodejs.org/docs/v0.4.1/api/modules.html

The idea of RPM is a little weird. Java already has a well-defined package
import system, but Rhino could add a layer on top of that I suppose. 
However I think that Rhino doesn't need that, if we get rhino-require 
right then the package manager for rhino would just be npm.

-- 
Michael Mathews
On Tuesday, 3 May 2011 at 07:37, Michael wrote: 
> Shortcomings are that it doesn't yet have encoded in it all the rules 
for resolving the location of the required module. To do that properly I 
would need to add the folder searching algorithm, including reading any 
package.json files to discover the location of main.
> 
> And yes, it really needs some test love.
> 
> On 3 May 2011, at 07:11, Tom Yandell <tom@yandell.me.uk> wrote:
> 
> > Cool, what shortcomings does it have? Thought about a testing framework? :-p
> > 
> > In other news, js-signals is now in NPM :-) The package name is "signals":
> > 
> > http://search.npmjs.org/#/signals 
> > 
> > Maybe what's needed is an R(hino)PM?
> > 
> > Tom
> > 
> > On 2 May 2011 18:35, Michael Mathews <micmath@gmail.com> wrote:
> > > 
> > > 
> > > -- 
> > > Michael Mathews
> > > On Monday, 2 May 2011 at 17:42, Tom Yandell wrote:
> > > > On 2 May 2011 13:33, Michael Mathews <micmath@gmail.com> wrote:
> > > > > Funny you should ask: https://github.com/visionmedia/node-growl
> > > > 
> > > > Heh, sweet. 
> > > > 
> > > > > 
> > > > > If there is a commonjs compliant module loader for rhino I sure 
as hell would like to know about it. I very much need that. I've had to 
write my own and it isn't perfect. 
> > > > 
> > > > Why not improve it, put it on github, encourage others to 
contribute, etc. (I'm ignoring the fact that you hate the community :-)?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > My gawd, you are cynical: https://github.com/micmath/Rhino-Require
> > > I look forward to your contributions.
> > > 
> > > 
> > > > > What do I consider exciting? Well, I agree that gherkin is 
interesting, but only because they tried to step outside the accepted way 
of doing things, and put human-usability first. 
> > > > 
> > > > I love the way it separates the description of the functionality 
being tested from the way it is being tested. This seems to be a big win 
for test maintainability (too often unit tests seem hard to maintain and 
brittle). Like I said earlier, BDD is a big area where I hope to develop 
Litmus - probably making use of (at least parts of) gherkin syntax and 
separation. BDD derailed litmus development for quite a few months while I
worked out where I thought it might fit into the unit testing picture. 
> > > > 
> > > > > For another example, in the documentation domain, I think 
docco[1] is pretty innovative (but to be honest I probably would never use
it). 
> > > > > 
> > > > 
> > > > 
> > > > Is interesting, but seems a bit of a novelty. I like to have 
nicely documented code and I'd also like to be able to link api docs to 
the source code being documented, but I don't think users should need to 
read the code to use the API. 
> > > > 
> > > > > So going in that direction in a creative way is what makes a 
product interesting, IMO.
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > I know what you mean, and I'm constantly looking at projects that 
are interesting, but often they're interesting because you think "I could 
use that idea" rather than "I could use that library" (or I do at least). 
In this case, I'm not creating a testing library to be interesting - I 
find it pretty hard to get excited by a testing library (using or 
developing). I just want something that's solid and lets me get the job 
done. 
> > > > 
> > > > > Just copying the same old xunit/qunit interface is conformant
> > > > > 
> > > > 
> > > > 
> > > > Heh, I was shooting more for ease of use of Test::More than xUnit 
:-) Qunit async api seems weird (similar to the way jake did his, so maybe
it's me that's weird) and a bit broken. xUnit (or Test::More) didn't have 
facilities for async tests, but otherwise I quite like they way they work.

> > > > 
> > > > > , but if you're going to be conformant with your API you damn 
well better be exciting in some other way (like "runs 100x faster!" or 
"integrat es directly into textmate!" etc).
> > > > > 
> > > > 
> > > > 
> > > > I expect that for large test suites, particularly those that 
perform a lot of async operations, litmus will be a lot faster. Dunno 
about 100x. Expect vim integration before textmate ;-) 
> > > > 
> > > > Tom
> > > > 
> > > > > 
> > > > > [1] http://jashkenas.github.com/docco/
> > > > > 
> > > > > -- 
> > > > > Michael Mathews
> > > > > On Monday, 2 May 2011 at 13:16, Tom Yandell wrote:
> > > > > > On 2 May 2011 12:13, Michael Mathews <micmath@gmail.com> wrote:
> > > > > > > Having fun building a testing framework is it's own reason! 
I'll probably use nodeunit for JSDoc though :)
> > > > > > > 
> > > > > > 
> > > > > >  Fair enough, looks like a decent choice. 
> > > > > > 
> > > > > > > 
> > > > > > > Some features I personally would love to see in a testing framework:
> > > > > > > 
> > > > > > > * runs equally well in Rhino, Node, or browser (can be 
completely host agnostic on at least a core level).
> > > > > > 
> > > > > > Is there a commonjs compliant module loader for rhino? I saw 
ringojs supports that, but I'm more interested in something standalone. 
> > > > > > 
> > > > > > Think I will work on browser support for litmus soon. The "out
of the box" browser support for nodeunit is interesting. It isn't like you
can run the same set of tests in the browser and command-line without 
extra work. This is what I want - I want to know my modules work in both 
the browser and in node.js (or other commonjs compliant environments), and
only have to maintain one set of tests. 
> > > > > > 
> > > > > > > * provides a beautiful, easy and exciting API
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > I'd like that too, but something that allows me to get the job
done would be okay. I;d be interested in what you consider to be 
beautiful, easy and exciting - gherkin is the one things that's caught my 
eye, which is why I'm going to integrate some of it into litmus. 
> > > > > > 
> > > > > > > * supports templates or plugins for handling the various 
events of a test run
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > With litmus, I've tried to keep the internal abstractions 
clean enough that people should be able to hook into them. It should be 
possible to add extra assertions, write formatters (both static and 
dynamic while the tests run) using the (documented in jsdoc) api. This 
should be even better when I replace the current event system with 
js-signals (it already got better when I integrated promised-io for the 
runs and async stuff). I'm leaving templates where they belong (IMO) - in 
a template library. I am interested in plugin systems though - both for 
this and micro/proton. 
> > > > > > 
> > > > > > > * trivial to set up to "watch" a folder of scripts and will 
automatically rerun itself whenever I save a change to my scripts
> > > > > > > 
> > > > > > 
> > > > > > Interesting, hadn't considered this as a goal up til now. 
Needs further consideration - how would a user experience test failures 
(does node-growl exist)? Is this a type of immediate continuous 
integration system? 
> > > > > > 
> > > > > > > 
> > > > > > > > runs as much as possible in parallel
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Is probably useful, but unless I have many hundreds of tests
(which, actually JSDoc 3 is approaching, at about 175 now) then this is 
not really a big deal for me. Although maybe that could be the main 
"point" of Litmus: it's the fastest testing tool for node?
> > > > > > > 
> > > > > > 
> > > > > > Speed is part of it, but what I really like is the change in 
development practices that comes with the rejection of static data. Making
things run in parallel isn't a feature you can add later if code is 
written to (mis)use late static binding to do mocking/stubbing I think. 
> > > > > > 
> > > > > > Thoughts?
> > > > > > 
> > > > > > Tom
> > > > > > 
> > > > > > > -- 
> > > > > > > Michael Mathews
> > > > > > > On Monday, 2 May 2011 at 12:01, Tom Yandell wrote:
> > > > > > > > On 2 May 2011 11:30, Michael Mathews <micmath@gmail.com> wrote:
> > > > > > > > > Interesting: https://github.com/nodejitsu/kyuri
> > > > > > > > > 
> > > > > > > > 
> > > > > > > >  Very interesting. Bit strange that it generates a 
skeleton from your features, which you then modify. What happens if you 
want to modify your features, do you modify the vows? Seems like a 
possible failing. 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The problem, for me trying to pick a testing tool for my
own projects, is I don't see what makes Litmus a better choice than the 
others that are available (possibly a problem of the docs?). This makes me
wonder if it isn't just a "learning exercise" by the authors, which is 
cool but I not a selling point for me as a user.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Heh, given litmus was completely undocumented until 
yesterday (other than inline jsdoc), things could improve there :-) 
Suggestions very welcome.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > JSDoc for example, differentiates itself from the other 
available doc tools as being the one that best understands the code it is 
documenting. The benefit is that you can write much shorter doc 
annotations and JSDoc can figure the rest out for you (in fact, you can 
use it to document code that has no annotation comments at all!). 
> > > > > > > > > 
> > > > > > > > > What's Litmus' main selling point? (either implemented 
or planned?)
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I mainly wrote litmus because no existing framework that I
found had the features I wanted and worked in the environments I wanted. 
There isn't really a single distinguishing USP, but I would hope that it 
has/will have the following features: 
> > > > > > > > 
> > > > > > > > * can be run in the browser and outside the browser
> > > > > > > > * can display test output nicely in both the browser and 
on the command line (both a static report and a more dynamic version while
the tests run)
> > > > > > > > * can test async code
> > > > > > > > * runs as much as possible in parallel
> > > > > > > > * supports skipping assertions
> > > > > > > > * makes it easy to test exceptions
> > > > > > > > * clean design, easy and fun to hack on
> > > > > > > >  * extensible - can add assertions, features, hook into 
events, etc.
> > > > > > > > * supports BDD (although I wasn't aware of this when I started it)
> > > > > > > > * uses libraries where appropriate (promised-io, 
js-signals, maybe spectrum in the future)
> > > > > > > > 
> > > > > > > > Agree that it's a difficult choice. I'm going to continue 
using (and developing) litmus until either it becomes really compelling, 
or something else that's really compelling comes along - I hope the former
as I have significant investment litmus :-) 
> > > > > > > > 
> > > > > > > > Tom
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > -- 
> > > > > > > > > Michael Mathews
> > > > > > > > > On Monday, 2 May 2011 at 07:41, Tom Yandell wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 2 May 2011 02:07, Michael <micmath@gmail.com> wrote:
> > > > > > > > > > > I'm very interested in testing libraries that are 
easy to run on either: node, rhino, or browser.
> > > > > > > > > > 
> > > > > > > > > > Me too. Well, I'm less concerned about using rhino 
myself, but would be happy to support it if it wasn't to onerous. 
> > > > > > > > > > 
> > > > > > > > > > >  Also I think the should.js syntax is cool.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Perhaps a personal preference thing, but I don't like 
spelling out sentences with chained method calls/property accesses. I love
the use of well named methods to make it clear what things are doing, but 
constructing the api to make english phrase possible seems too magical. 
> > > > > > > > > > 
> > > > > > > > > > > What makes litmus better/different than, oh say, 
nodeunit, for example?
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Not used nodeunit, but it does look pretty good. 
Didn't really like what they say about async tests. An explicit design 
goal of litmus is being able to run tests and async tests concurrently (in
as much as you ever can in JavaScript). Doing this and statically 
replacing bits of API (as their example suggests) would cause big 
problems, which is why (it seems to me) their tests run in series. I'd 
like to get away from abusing late static binding to do mocking, and use 
(instance based) dependency injection instead - i.e. design software to be
testable in expected ways, rather than doing it by mucking about in other 
people's libraries. 
> > > > > > > > > > 
> > > > > > > > > > Thoughts?
> > > > > > > > > > 
> > > > > > > > > > Tom
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 1 May 2011, at 18:21, Tom Yandell 
<tom@yandell.me.uk> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > Have just push changes to use.no.de containing 
litmus docs. Not finished or published to the site yet, but would still 
appreciate any feedback:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus.pub.spv 
> > > > > > > > > > > > 
https://github.com/tomyan/use.no.de/blob/master/views/litmus/assertions.pub.spv
> > > > > > > > > > > > 
> > > > > > > > > > > > Also, I've sent a pull request to Miller Medeiros 
for getting JS Signals into NPM. Going to wait for this to happen before 
integrating with litmus: 
> > > > > > > > > > > > 
> > > > > > > > > > > > https://github.com/millermedeiros/js-signals/issues/20 
> > > > > > > > > > > > https://github.com/millermedeiros/js-signals/issues/21
> > > > > > > > > > > > 
> > > > > > > > > > > > Tom 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> >