My objective is to create a dialog on the client testing paradigms with Ember.js
Ember's Unit testing style is a bit of a throwback for me personally. I worked in the software engineering research lab as an undergraduate in university and I was fortunate to have a professor introduce the concept to me much before it found it's way into any formal curriculum. My own tenacity is responsible for the actual learning.
In Testing one of the primary objectives is to evaluate the correctness of a piece of code , layer of code, subsystem, or less frequently the entire system.
First some vocabulary that seems to be in use in the community, next I will talk about Ember Test Helpers, and finally i will mention QUnit Asyncronous Testing.
I'm going to order these from complex to simple.
Acceptance Test :
This is a client => server => client comprehensive test that involves invocation of api 'end-points' as well as minimal use of mocking
Integration Test :
This is a client => mock_server => client comprehensive test that involves exercise of the client code with a mock implementation of the interface that is expected of the service. It can be completely functional or may mock out parts of the client to focus the test on a particular subsystem.
This is a generic term for verifying that the expectations of a particular method or function are operating correctly. I have also heard this term used to describe a set of tests about a particular object.
The goal in testing is to validate the correctness of the system or a sub-unit of the system. If you can verify individual sub-units and functioning correctly then by collection and coverage you can increase the confidence that the entire system is functioning.
Ember uses QUnit for testing. This is in the traditional test unit style of assertion / expectation - and is syntactically different from behavior driven testing - which is effectively the same only organized more about expectation of behavior than simply data-correctness.
Ember Integration Test Helpers
Ember-Test provides the developer with a variety of helpers for the purpose of integration testing
These are not needed for typical unit-testing of objects - which should be considered as the first and most useful tool - especially when building a library.
If you think about software as a tree of node and edge where each node is your tree - effective unit testing is testing of the node, and mocking of the edges. For simplicity at times it can be effective to test a group of objects in concert - this is a sign of coupling - too much coupling and you'll have a british television show - and a headache when you try to re-use an object independently.
test "default template", ->
ok exists("*"), "Found Some HTML"
In this example 'ok' is a QUNIT assertion helper function - the complete list is here
** Final Words **
Unit Testing is a way to maintain correctness of a system, improve development speed, manage the structure of a system, and it also tastes great on toast.
Tests are meant to change, they can be deleted, rewritten, a test that is brittle is better deleted, tests must adapt and change and be removed - without them - any system - even a simple system will begin to degrade - I've seen this happen in a matter of 2 weeks.
Software without automated unit tests is like a steel car without rust-proofing.
There is no substitute for testing in software. Testing in software is part of a comprehensive discipline for establishing quality and repeatability. I have been learning about testing for the last 10 years and I am still learning.
What I know deeply, through repeated experience - is that with the use of testing your software will improve and your quality of work will improve. Software Testing, despite any difficulty, pays back dividends.
** Errata **