Of course, when writing libraries it’s a whole different game. With JohoDB you’re going to be deploying to a moving specification, with new technology and a wide variety of browsers. There’s no option but to test every feature if I’m serious about going live with it. I pretty quickly went with Jasmine, and have been able to customise it’s output very easily to get what I wanted out of my test page.
Here’s some features that come out of the box with Jasmine:
- Create your test suites in a hierarchical structure to make it easier to follow.
- You can click on individual test suites to filter it down, speeding up testing when you’re working on a particular feature. In my case I customised it a little so some ‘setup suites’ would always run.
- Each error come with messages and a traceback to help you get started on the bug hunt.
- Asynchronous functions can be given a time limit, again with a message so you can figure out where the chain broke.
- Everything is run through functions, so if you need to run a test suite multiple times with different input you can do so easily. In my case I have a function with tests, and then it gets passed the IDB database, and then the SQL Database. That way I know both are being tested with exactly the same API calls.
To be specific I’ve now got the database encapsulated properly so I can run the two side by side, no dramas, and delete / rebuild the database for every single test suite. It really is a stress test for how the promise system is holding up to keep the API manageable, and it’s going great so far.
There’s still more work to do, but once the existing library is well tested, It’ll be time to build up features so I can reach a version to test in an actual application. I can’t wait.