JavaScript Test integration in Kitoon

[debloper]

Context: we've had a brief internal and in-person discussion with @kmkanagaraj to come up to a conclusion that integrating tests in very much required, and shouldn't be delayed any further.

Resolution: @kmkanagaraj has proposed the use of Mocha for the purpose, and I agree with him. This is the thread to discuss why we're choosing Mocha, for future references.

Please participate in the discussion if you have points to add, rectify or argue on.

[debloper]

Shortlisting

QUnit, Jasmine and Mocha are the most generic, well maintained and popular JS testing frameworks out there. There are many more with various objectives/focuses (angular's Karma & Protector, test-suits' & browsers' interop TestSwarm, end-to-end feature-rich Nightwatch, concurrency handling AVA etc.), but we aren't primarily concerned about the focused-challenges they try to overcome.

The Winner

The top three shortlisted picks, IMO, can be explained as:

• QUnit: easiest to start but hardest to scale. Also, very verbose to handle logical complexity
• Jasmine: the hipster & the most popular one. But does too many things, introducing overheads
• Mocha: the underestimated shy-kid. Flexibility++, Overheads-- and doesn't impose best-practices

For our purpose of keeping the code functionally accurate & non-regressing with lightweight frontend evaluations, Mocha makes the most sense. It's also most flexible & extensible, hence theoretically not missing out on features.

Cons

• Doesn't come integrated with an assertion library
• Doesn't have a pre-defined syntax for writing test cases
• Doesn't come integrated with Selenium, out of the box, for UX testing

Pros

• Can use a range of assertion libraries*^Appendix, which ever is preferred
• Doesn't have a pre-defined syntax for writing test cases
• Can be extended to use Selenium if needed
• Supports JavaScript Promises

*Appendix

By picking Mocha, we're also left with selecting an assertion library to make it work. The suggested ones are all great. I'm split between picking should.js vs expect.js for this, with a little more weight to expect.js.

Should.js is the most feature-rich and flexible, at the cost of being way too high entry-threshold. Whereas, expect.js is based on should.js like philosophy but sweetened to make it easier and nicer to write logical expressions without losing much.

For our purpose (as we aren't going into or have started as TDD) the extra-richness of should.js will probably never be required, hence, my suggestion is to go with expect.js.