Skip to content

Tags: bentomas/node-async-testing

Tags

v0.4.0

Toggle v0.4.0's commit message
Release candidate for v0.4.0

v0.3.2

Toggle v0.3.2's commit message
Version 0.3.2.

Make node-async-testing extendable.
Fix bugs in web runner.

v0.3.0

Toggle v0.3.0's commit message
Add disclaimer about browser support for the web runner

v0.2.1

Toggle v0.2.1's commit message
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.

v0.1.0

Toggle v0.1.0's commit message
The last stable release before I drastically change the API.