Reduce size further by not having assertions baked in

[Raynos]

If a user wants an assertion mechanism just show them the simplest one

function assert(boolean, message) {
    if (!boolean) console.warn(message)
}

test("foo", function () {
    assert(1 === 1, "obvouis")
    assert(1 === 0, "failure")
})

If you want the stack trace hackery to be baked in then change your test logic to catch throw exceptions in the function and show useful stack trace information.

Catching exceptions in the test block means your tests become fail fast instead of showing multiple failures in the test block

[padolsey]

Thanks for the suggestions.

I think your simple assert function is all that's needed for many cases, but those cases are not what twtl is made for. If a user wants that then there's no advantage to them in including an entire lib for a simple assert. And for such a simple thing there is also console.assert(...).

When you say the tests are 'fail fast', I'm not sure what you mean. Errors are only thrown to be immediately catched and then a stack trace is retrieved. The remaining tests in a test 'block' will still run, unless the user's test code throws an error itself.

---

FWIW, my aim with twtl was to make something a little more useful than console.assert(...) which would work cross-browser (or at least across the browsers that I tend to develop on). I chose an API that resembled Jasmine because of its expressive power. A simple assert with a boolean offers no introspection on tests reports -- and this is something I really wanted and hence why I ended up making twtl.

[Raynos]

try { f() } catch (err) { ... } If there are multiple assertions in f then the first one that throws terminates the execution of the entire function.

But as I understand what you've really made is an assertion library with a small test wrapper on the side. That's a different story.