joewalnes / jstinytest

Tiniest simplest unit testing library for JavaScript

Tiniest JavaScript unit testing library

This is an in-browser JavaScript library I've been using for years. It's so small and simple that it never occured to me to open source it until I saw all the overly complicated alternatives that are out there.

If you're looking for a JavaScript library full of features or install guides that say things like grunt, npm or bower, you've come to the wrong place. Sorry, this probably isn't for you. Move along now.

If you're looking for a quick way to unit-test a JavaScript function/object in a web-page and don't want to get bogged down in frameworks, you've come to the right place. Take a seat... no scratch that, you'll have everything you need in a few seconds so you may as well remain standing.

• Download tinytest.js
• Example

10 second tutorial

Download tinytest.js and put it somewhere in your web directory.

Let's say you have a function in adder.js:

function add(a, b) {
  return a + b;
}

Create a test page called adder-test.html (you can name it anything). This includes your code under test, tinytest.js and defines your tests:

<script src="tinytest.js"></script>
<script src="adder.js"></script>
<script>
 tests({

   'adds numbers': function() {
     eq(6, add(2, 4));
     eq(6.4, add(2.4, 4));
   },

   'subtracts numbers': function() {
     eq(-2, add(2, -4)); 
   },

 });
</script>

Open the page in your browser. Green is good. Red is bad. If it's red, look in the JavaScript console for messages.

That's it!

Don't believe me? Here's the source and result.

What else?

If your tests fail, you'll get stack traces:

Function reference

// Force a failure
fail(reason);

// Assert expression is truthy (fail with reason)
assert(expression, reason);

// Assert expected == actual
assertEquals(expected, actual)
eq(expected, actual) // Alias for assertEquals

// Assert expected === actual
assertStrictEquals(expected, actual)

Errm that's it. Now stop wasting time - go test that function.

But, but, but. What about feature X?

It probably doesn't have it. If you need that, you'll probably find it in one of the many more sophisticated frameworks out there. A more detailed discussion can be found here.

Projects using TinyTest

• Filtrex - A simple, safe, JavaScript Filter Expression compiler (Tests) (Results)

Other stuff

I also have TinyTest for C that follows similar principles of simplicity.

Now check out my other GitHub projects and follow @joewalnes on that Twitter thing.

jstinytest's Issues

[Question] Is this package available via npm or other source control?

Potentially unnecessary use of bind and apply

Hi Joe,

First of all, thank you for sharing such an easy to understand testing tool! It's been a great in learning javascript and understanding the principles of testing, under the guidance and method of
@gordonmzhu at watchandcode.com.

After looking at the code in detail, I have some suggestions for improving the code. As far as I can tell, the use of bind() when creating test method aliases is currently superfluous. var fail = TinyTest.fail, without binding, would be sufficient as the variable has access to the necessary tinytest scope when invoking it's stored function.

Similarly, testAction.apply(this); can be run without apply, as we do not require the value of this to be passed through to the testAction function for normal operation.

So far, I have not been able to think of any use cases for bind/apply within tinytest.js. If the test methods themselves were to be modified in the future, and those modifications used this, it would already point to the tinytest object by default. In addition, I cannot think of a use case for why the API user would want to reference the tinytest object within test code itself; currently the tinytest code is protected within the scope of its API, and this seems to be an advantage to me.

It would be great to hear if you have any feedback on these thoughts. I would be happy to submit a PR for this small modification. The biggest benefit I can think of is having a less ambiguous code base for beginners - @gordonmzhu continues to use your tool for educational purposes.

Thanks also to @adilzeshan for helping me to test the above ideas.

how to handle an error thrown from a promise chain?

I found that when assertions happen in a then clause in a promise chain, failures were logged generically (uncaught error in promise), but the screen still turned green.

So I'm trying a failHard method in the kit:

    failHard: function() {
        document.body.style.backgroundColor = red;
    }

along with tests that use the catch pattern shown here:

'creates group picklist with > 1 groups when token': function() {
   var groupContainer = createGroupContainer();
   createGroupInputForm(groupContainer);
   waitSeconds(2)
     .then( r => {
       let groupList = getById('groupsList');
       assert(groupList);
       let options = groupList.querySelectorAll('option');
       assert(groupList.length > 1, `expected > 1, got ${groupList.length}`);
     })
     .catch (e => {
       console.log(e.message);
       failHard();
     })
     .finally(removeGroupContainer);
 },

It's not completely satisfactory. If I write the assertion as, for example,

assert(groupList.length == 1, `expected 1, got ${groupList.length}`);

which will fail, the log looks like this:

Test: creates group picklist with > 1 groups when token OK
Test: creates group picklist with 1 group when no token OK
test.html:88 assert(): expected 1, got 29

In other words it reports OK before it finds out that it wasn't OK. Also, you can' t tell from the log that the failure was for the when token test not for when no token. I wonder if there's a a non-clever way to avoid the erroneous OK? No worries if not, since I'll always look in the console when the screen goes red.

Thanks for this little gem. It's a breath of fresh air!