Allow testing just one test, plus

[ianb]

Sometimes you want to test just what's breaking. Tests often build up cross-dependencies, but at least it should be possible to test one.

Some things should still be marked as "setup" tests that always are run. Probably like it used to be, <pre class="commenttest setup">

AbortSection could also be reintroduced.

[boxed]

How about tests that SHOULD have cross-dependencies? How would you mark up dependent blocks?

[ianb]

At a certain point having large bits of logic between tests seems like it's encouraging some questionable complexity. You can still use things like <pre src="..."> to share code between tests (or just run a function/etc), and break larger chunks of functionality into completely separate tests. I could imagine something like <pre class="commenttest setup" data-requires="other-test">...</pre> which would make sure <pre id="other-test"> was run – but it feels like the HTML is becoming code at that point.

[boxed]

A way to wait at some point for the completion of an event would be pretty reasonable I think. It's a bit unfortunate that the "wait" function currently doesn't actually wait. An API that would make more sense to me would be something like:

// = SECTION Some test
someLongRunningFunction(function(data) {
    // completion handler
    markComplete();
    baz = data;
});

foo(); // this one sets the variable fooDone
markCompleteWhen(function(){return fooDone;})

waitForCompletions(); // At this point we really DO wait

print(baz);
// => some output
print(fooDone);
// => true

Right now the API has a function called "wait" that doesn't actually wait. To check the result you have to create a new section, which is really unintuitive.

[boxed]

Hmm.. maybe to go with the current philosophy instead of "waitForCompletions();" it should be "// = WAIT" or "// = RESULTS" and then check the results after that. It would tie in nicer with the parsing of sections. It could function similarly to a section boundary but not render as a new pre block.

[ianb]

What I do in practice is this:

foo();
wait(condition);
// =>
print(fooDone);
// => true

That is, a dummy/empty // => causes the wait to actually happen. Right now we aren't parsing anything in between the // => comments, so we can't "pause" anything there. Also we really can't pause in the middle of a function – so while it's not impossible to actually parse the Javascript and look for a function by a specific name and break the example there, it's still going to throw people off.

We could actually name that like // = WAIT but I don't know if that really clarifies things that much more?

[boxed]

Oh, I didn't know that a dummy // => was enough to make the wait happen, I was under the impression you had to have a new section. Well, I guess this is even more reason to rename things and add clarifications :P

I think renaming wait() to something like completeWhen/registerWait and then doing // = WAIT or // = COMPLETED would be MUCH clearer. Having a function called 'wait' that doesn't actually wait is a pretty clear violation of Principle of Least Surprise, and so are the empty output checks.