• Oct 30, 2010


    Release candidate for v0.4.0
  • Sep 15, 2010


    Version 0.3.2.
    Make node-async-testing extendable.
    Fix bugs in web runner.
  • Sep 4, 2010


    Add disclaimer about browser support for the web runner
  • Aug 10, 2010


    Version 0.2.x is a complete rewriting of node-async-testing from the
    ground up.  Pretty much everything about node-async-testing has changed.
    But I hope you will agree that I have kept the same spirit of the first
    version and have even better addressed the goals listed in the README.
    New changes:
    + Tests can be run in parallel to have them run very quickly.  The
    default is still to have each test run consecutively one after another
    for the most accurate results.
    + No more do we try and guess if a test is synchronous. I got bit by
    that too many times when I changed a test to be asynchronous but forgot
    to update the arguments.
    + The suite runner is now much more robust, it can take modules, file
    names, directory names or some combination there of.
    + When running individual test files from the command line it is now
    easy to pass in arguments to change the output or the behaivor.  For
    example, it is now trivially easy to run one specific test in a suite.
    + Colored output. I'm quite excited about this, but I suppose I should
    add an option to disable it.
    + It is now possible to easily write your own test runners and to format
    the results however you'd like.
    Things that are now a bit more work:
    + We now assume that the default use case is to have one test suite per
    file.  It is still easy to have more than one test suite in a file but
    we have no examples of it. Unfortunately, however if you have more than
    one suite it a file your suites don't get to have names.  As
    node-async-testing gets the name of a suite from the file it is in. I'd
    be interested in hearing suggestions for how to set a name in a suite in
    a way that doesn't feel tacked on. Even though I am talking about
    tacking this on...  :)
    + Setup/teardown functions are not nearly as straight-forward. I felt
    that an even simpler and easier system for writing tests out-weighed the
    convenience of the previous setup/teardown functions.  Now you have to
    write your setup/teardown functions as a wrapper function which take a
    test and return a new test.  No functionallity has been lost, it just
    isn't as convenient.
  • Jun 18, 2010


    The last stable release before I drastically change the API.