Catch-style unit testing in JavaScript (phase 1)
Overall Design

For such a small amount of code, I find the logic extremely difficult to follow. I understand what is happening at a high level, but it seems every function is responsible for managing everything, and program control bounces around a lot.

As an example, the final function assigned to SECTION has several responsibilities:


Capture the enclosing section and current next task.
Do nothing if this new section should be skipped.
Create a new next task that will either

rerun the test case (if more sections have been added),
run the previous next task (if there is one), or
do nothing.

Add the new section to the enclosing section.

BTW, under what condition does updateSubsection not create a new section? I can see it looks for a section with the same name, but is that supposed/allowed to happen?
Finally, run the new section.


That's way too much work for one nine-line function to do.

As a first step, add a TestCase class (subclass of Section) to own the overall state of running a single test case, and move the logic from the last two functions into it, breaking them up into smaller functions. While test cases are run sequentially, I would move context and nextTask into this new class as I believe they belong to a single test case run.

Names

Most of the variable names are pretty clear, but as I dig into the code some are misleading.


context sounds more like a map of values passed to each section rather than a stack of running sections. I would rename it to reflect that nature, e.g., activeSections.
subsectionsEncountered is a little cumbersome; how about the more standard subsectionCount? And subsectionIndex only tells me it's an index into some container--not why that subsection is special. I'd go with activeSubsectionIndex though I would prefer to store the actual Section instance in it and drop the Index suffix if possible.
You're creating a tree of sections, and parent is more obvious than outer.


Other Thoughts

I'd be tempted to drop the stack of sections (context) in favor of storing just the active section since that's all you need. To pop a completed section off the stack, a) store a reference to the parent section in each section instance and b) assign the parent to activeSection after each section completes.

Finally, you need to handle exceptions so other sections can be run. You should be able to do it once in Section.prototype.run.

On to Phase Two!

I'm very curious to see this in action. With QUnit I am often forced to perform the same actions on the fixture as a previous test did in order to set up the current test. This causes code duplication whereas the whole point of setting up a fixture is to avoid it.

In Java I've been building separate fixture classes that provide methods for setting up common fixture states that can be reused across many tests. While that's helpful, it's not as easy to do in JavaScript.