Unit testing is fun. Unit testing when you have to emulate a browser doing HTTP requests is even more fun. Unit testing when you have to emulate a browser logging in and then doing more HTTP requests is... etc.

I got some practice using the Mocha JavaScript unit testing framework today while I finished creating some unit tests for our CSV export feature. We ended up having to code in config variables to disable features like the login system and the new heartbeat feature (which my team mate created to improve the stability of the system) just to get my unit tests to run. But in the end, I was successful:


It's just a start. Most of my time was spent getting the testing going and creating the helper functions I'll use to speed up making more tests. We can now quickly create more tests later on to make sure our MongoDB joining works well, and to make sure changing our schema if we need to doesn't break the joining functionality.

One thing I'm bad for is writing code blindly, never using TDD (test driven development) or BDD (behaviour driven development) techniques. I think they're good in theory. They can help avoid feature creep (by letting you know when you've coded "enough") and allow you to retest your code as you go, giving you confidence you didn't break anything. So I'm glad I got to practice this. We'll need to have a thorough unit testing system in place when we ship anyways.

As we shift into the UAT (User Affinity Tool) portion of the project, which will involve writing more code, I will try to write unit tests ahead of time before coding the features, or perhaps code unit tests while my team mate codes features etc.

Note: This was originally posted on the blog I used for my co-op term while at Seneca College (mswelke.wordpress.com) before being imported here.