Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16493 > unrolled thread

Unit test framework recommendations?

Back to article view | Back to comp.lang.javascript

Contents

  Unit test framework recommendations? Patricia Shanahan <pats@acm.org> - 2012-10-09 09:10 +0100
    Re: Unit test framework recommendations? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-09 10:40 -0700
    Re: Unit test framework recommendations? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-09 21:19 +0200
      Re: Unit test framework recommendations? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-09 21:50 +0200
      Re: Unit test framework recommendations? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-10 07:24 -0700
        Re: Unit test framework recommendations? Patricia Shanahan <pats@acm.org> - 2012-10-10 22:14 +0100
          Re: Unit test framework recommendations? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-11 06:19 -0700
        Re: Unit test framework recommendations? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-14 00:11 +0200
          Re: Unit test framework recommendations? Patricia Shanahan <pats@acm.org> - 2012-10-13 23:49 +0100
          Re: Unit test framework recommendations? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-14 13:17 -0700

#16493 — Unit test framework recommendations?

I like to do test driven development, and generate a lot of unit tests,
so I need a framework to organize and run them.

I need to pick one early, because some of my program fragments from
learning the language may become testable units in my actual
application. For example, I'm thinking of using a storage wrapper that I
will need in my application as my next major exercise. Writing that will
check whether I have understood the storage.

Does the group have a recommendation for a unit test framework for
JavaScript?

I am extremely familiar with JUnit, and note that JsUnit is based on it,
but I'm concerned that it may not be very actively maintained. Also,
porting something designed for one language for use with another, very
different, language does not always get the best results. If there is a
better tool for JavaScript I would be happy to learn it.

Patricia

[toc] | [next] | [standalone]

#16506

Patricia Shanahan wrote:
> Does the group have a recommendation for a unit test framework for
> JavaScript?

I very much doubt the group will have a consensus.

But I'll willing to give you my own recommendations, for what they're
worth.  I've used a number of them, including QUnit, YUI Test, JSUnit,
and RhinoUnit.  The ones I would most recommend are Jasmine and
JsTestDriver.

Jasmine is a BDD framework, and that might feel a bit different from
an XUnit framework, but it's not all that different.  It's really easy
to get going with, and the tests are easy to read and write.

JsTestDriver is a little harder to set up, but has a nice advantage of
being very easy to integrate into a build environment with very simple
testing from multiple browsers and operating systems against your
single build server.  (I hear Buster is similar and has some
advantages, but I haven't tried it.)  Its standard tests are also very
easy to work with, although its asynchronous tests are a bit clunky.

In any test environment I've used, I've found the Sinon mocking/
stubbing framework invaluable, as well.  It significantly simplifies
mocking out complex dependencies.

I've still to settle on any really good functional testing tool, so if
you're looking for one I don't have a really strong recommendation,
although FuncUnit *looks* pretty good.  In any case I imagine
PhantomJS is likely to be part of any serious functional testing
environment these days.

I'm sure others will chime in with their tools.  The barrier to entry
in creating a reasonably robust testing framework is pretty low, so
there are many of them out there.  If you find yourself spending a lot
of time working in Javascript, I recommend creating your own, not
really to use for the long term, but because it's an excellent
learning experience for an intermediate developer.  But then most
likely the best bet is to throw it away in favor of one of the
established ones unless it is amazingly ahead of them all.

Good luck,

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16514

Patricia Shanahan wrote:

> Does the group have a recommendation for a unit test framework for
> JavaScript?
> 
> I am extremely familiar with JUnit, and note that JsUnit is based on it,
> but I'm concerned that it may not be very actively maintained.

It is not, indeed.  I have stopped using JsUnit (after I had to fix some 
invalid markup in the latest 2.1 beta – always a bad sign in a Web 
application) when it stopped working in newer browsers because of security 
issues.  So I can safely and strongly recommend against using it anymore.

> Also, porting something designed for one language for use with another,
> very different, language does not always get the best results. If there is
> a better tool for JavaScript I would be happy to learn it.

I have found jasmine too intuitive (very un-JUnit-like, which its creators 
present as a virtue; but I had come to appreciate the clear structure of 
JUnit tests as well, whereas Jasmine appears to me as sort of a childish, 
jQuery-like way of writing unit test by comparison).

So I have written my own script for unit tests; I am not sure if it can be 
called a framework.  You can find it at 

<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Ftest%2Ftest.js>

(which for unknown reasons is not syntax-highlighted at the moment like the 
other code in the repository).  See corresponding entries in the changelog 
<http://Pointedears.de/websvn/log.php?repname=JSX&path=%2Ftrunk%2Ftest%2F&isdir=1&> 
for more.

JSX:test.js is (IMHO) JUnit-like in structure, but because I would not want 
to go down the road of object iteration and looking for and requiring 
`test*' methods, you would define your tests as functions in an Array or in 
Objects referred to from an Array.  Test results are written to the error 
console or, if the document tree had been loaded, appended to the test 
document, or as a last resort, can be displayed with window.alert().

Although I have not designed test.js to work on mobile devices, I have found 
test.js to run in browsers on my HTC Sensation (Android) and iPhone 3G just 
as well.

One thing that test.js is not capable of is combining several unit tests.  
But maybe because testing in isolation is the very point of unit tests (as 
opposed to integration tests), it might never get that capability later.
(I have not found a need for that yet when testing my code.)

You can find an example of a real unit test using test.js, that should be 
self-explaining, at

<http://PointedEars.de/scripts/test/regexp>

Please let me know what you think of test.js and of any ideas you might have 
to improve it.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#16516

Thomas 'PointedEars' Lahn wrote:

> So I have written my own script for unit tests; I am not sure if it can be
> called a framework.  You can find it at
> 
> 
<http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Ftest%2Ftest.js>
> 
> (which for unknown reasons is not syntax-highlighted at the moment like
> the other code in the repository).  […]

JFTR: Setting svn:mime-type to text/javascript *prevented* the resource from 
being treated as repository content by WebSVN.  Therefore, that property has 
been removed.  Please drop me a note if you find other repository resources 
behaving the same way.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#16531

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
>> Does the group have a recommendation for a unit test framework for
>> JavaScript? [ ... ]
> [ ... ]
> I have found jasmine too intuitive

That's a very unusual aspersion to cast.

>                                    (very un-JUnit-like, which its creators
> present as a virtue; but I had come to appreciate the clear structure of
> JUnit tests as well, whereas Jasmine appears to me as sort of a childish,
> jQuery-like way of writing unit test by comparison).

I'm not entirely sold on Behavior-Driven Development, but that's the
style of BDD, and not something specific to Jasmine.  But it's only
slightly more verbose than JUnit and I think the intent of the tests
is substantially more clear:


    describe("The 'wordTester' functor', function() {
      var fooTest = wordTester("foo");

      it("matches whole words", function() {
        expect(fooTest("contains foo and bar")).toBe(true)
      });
      it("doesn't match nested words", function() {
        expect(fooTest("foolish tomfoolery seafood")).not.toBe(true)
      });
    });

I find that intuitive (which I write with no opprobrium!) and quite
useful for a large team environment where another user can learn much
more about the use of a component from well-written tests than from
copious documentation.


> So I have written my own script for unit tests; I am not sure if it can be
> called a framework.  You can find it at
>
> <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Ftest%2Ftest.js>
> [ ... ]

I look forward to playing with it.  I've read through around two dozen
unit test systems like this in the past year, mostly for my own
amusement.  I wrote my own, and promptly threw it away as I didn't
find it really gained anything useful on the two I'm using now.  But
it was interesting to do it, and it's very educational to compare the
varied approaches people have to this problem.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16544

Scott Sauyet wrote:
...
> I'm not entirely sold on Behavior-Driven Development, but that's the
> style of BDD, and not something specific to Jasmine.  But it's only
> slightly more verbose than JUnit and I think the intent of the tests
> is substantially more clear:
...

I must admit my ignorance about Behavior-Driven Development. Could you
point me to a good web page about it?

Patricia

[toc] | [prev] | [next] | [standalone]

#16552

Patricia Shanahan wrote:
> Scott Sauyet wrote:
>
>> I'm not entirely sold on Behavior-Driven Development, but that's the
>> style of BDD, and not something specific to Jasmine.  But it's only
>> slightly more verbose than JUnit and I think the intent of the tests
>> is substantially more clear:
> ...
>
> I must admit my ignorance about Behavior-Driven Development. Could you
> point me to a good web page about it?

This is a reasonable short introduction:

    <http://dannorth.net/introducing-bdd/>

This Wiki has much more information:

    <http://behaviour-driven.org/>

The Ruby community has especially taken to BDD, and two of the most
popular testing frameworks for Ruby are

    RSpec: <http://rspec.info/>
    Cucumber: <http://cukes.info/>

There are similar ones to both of these for most languages, though,
including Cucumber.js:

    <https://github.com/cucumber/cucumber-js>

And Jasmine seems by far the most used BDD framework for Javascript:

    <http://pivotal.github.com/jasmine/>

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16617

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> Does the group have a recommendation for a unit test framework for
>>> JavaScript? [ ... ]
>> [ ... ]
>> I have found jasmine too intuitive
> 
> That's a very unusual aspersion to cast.

Your internal error-correction is borken; it should have prefixed "un" to 
the adjective automatically.
 
>>                                    (very un-JUnit-like, which its
>>                                    creators
>> present as a virtue; but I had come to appreciate the clear structure of
>> JUnit tests as well, whereas Jasmine appears to me as sort of a childish,
>> jQuery-like way of writing unit test by comparison).
> 
> I'm not entirely sold on Behavior-Driven Development, but that's the
> style of BDD, and not something specific to Jasmine. […]
> 
>     describe("The 'wordTester' functor', function() {
>       var fooTest = wordTester("foo");
> 
>       it("matches whole words", function() {
>         expect(fooTest("contains foo and bar")).toBe(true)
>       });
>       it("doesn't match nested words", function() {
>         expect(fooTest("foolish tomfoolery seafood")).not.toBe(true)
>       });
>     });

If BDD (whoever coined that term again?) means that code is written like the 
above, so that it can be read from left to right like natural language, 
while completely ignoring sound and proven concepts of (object-oriented) 
programming (such as that namespaces should be used, method identifiers 
should be verbs and _not_ nouns, data properties should be nouns or 
adjectives, aso.), then I skip on learning (more about) BDD.


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#16622

Thomas 'PointedEars' Lahn wrote:
...
> If BDD (whoever coined that term again?) means that code is written like the 
> above, so that it can be read from left to right like natural language, 
> while completely ignoring sound and proven concepts of (object-oriented) 
> programming (such as that namespaces should be used, method identifiers 
> should be verbs and _not_ nouns, data properties should be nouns or 
> adjectives, aso.), then I skip on learning (more about) BDD.

I am having similar problems with BDD. I may give it a try later, but I
don't want to deal with something that different along with learning a
programming language.

Patricia

[toc] | [prev] | [next] | [standalone]

#16638

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Patricia Shanahan wrote:
>>>> Does the group have a recommendation for a unit test framework for
>>>> JavaScript? [ ... ]

>>> I have found jasmine too intuitive
>
>> That's a very unusual aspersion to cast.
>
> Your internal error-correction is borken; it should have prefixed "un" to
> the adjective automatically.

Ah, yes, I reversed the antiundisinversification switch.  I apologize.

>>>                          (very un-JUnit-like, which its creators
>>> present as a virtue; but I had come to appreciate the clear structure of
>>> JUnit tests as well, whereas Jasmine appears to me as sort of a childish,
>>> jQuery-like way of writing unit test by comparison).
>
>> I'm not entirely sold on Behavior-Driven Development, but that's the
>> style of BDD, and not something specific to Jasmine. […]
>
>>     describe("The 'wordTester' functor', function() {
>>       var fooTest = wordTester("foo");
>
>>       it("matches whole words", function() {
>>         expect(fooTest("contains foo and bar")).toBe(true)
>>       });
>>       it("doesn't match nested words", function() {
>>         expect(fooTest("foolish tomfoolery seafood")).not.toBe(true)
>>       });
>>     });
>
> If BDD (whoever coined that term again?) means that code is written like the

Dan North, I believe: <http://dannorth.net/introducing-bdd/>

> above, so that it can be read from left to right like natural language,
> while completely ignoring sound and proven concepts of (object-oriented)
> programming (such as that namespaces should be used, method identifiers
> should be verbs and _not_ nouns, data properties should be nouns or
> adjectives, aso.), then I skip on learning (more about) BDD.

BDD as a discipline (at least in my limited understanding) makes no
such requirements.  It's mostly about specifying system behavior in a
consistent manner, and finding ways to turn specifications that would
be recognized by non-technical business owners into automated tests.

But I'm going to disagree that there is something unsound about the
API.  (If you're talking about the test variable created, then
certainly, I should have named it `testFoo` rather than `fooTest`, but
that's clearly not the central point here.)  When you discuss the
"sound and proven concepts of (object-oriented) programming", I hear
echos of lessons learned from very different styles of language.  Most
of them are statically-typed, many are single-paradigm (that is, for
instance, Object-Oriented only), and they often have little to do with
the dynamically-typed, multip-paradigm family of languages often
called Javascript.

You suggest that method identifiers should be verbs, but when
functions are first-class citizens, no functions can really serve only
as OO methods.  But it's hard to say that objects should be named by
nouns and functions as verbs since all functions *are* objects.

I'm not sure where you see the need for namespaces here.  If you're
talking about the `wordTester` function under test, since we haven't
seen the whole test suite, it might well be namespaced.  If you're
talking about the test framework code, I would not expect to have to
use namespaces to use this code from within a test suite, no more than
is necessary from most other test frameworks I've seen.  But more
fundamentally, with the various module loading possibilities available
now, I think namespacing is probably going to be in significant
decline.  If I can declare my dependencies and have a module loader
supply them directly to me, the entire need to access such namespaced
objects might go away.

As I said, I'm still not entirely convinced by BDD.  I've used it for
a few smaller projects of my own, but not on larger projects with many
other developers.  I like what I see, and having tests that read well
is surprisingly helpful, but until I can try it on something larger,
I'll withhold final judgment.

  -- Scott

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web