Writing packages Cheat Sheet (DRAFT) by [deleted]

Reliab­ility:
In a web applic­ation (not a web site), there are multiple depend­encies on any given package or control. This means that simply verifying a control works as intended in one spot in the applic­ation is relatively sketchy assurance that it works, especially if making changes when it is already in use.

Collab­ora­tion:
Write tests against the behaviors you want a package to have. When someone else changes the behavior, they then know they have broken something that was required for a reason.

Regres­sion:
Something is broken, write a failing test, fix the test, it will never surprise you again.

Anytime the public facing behavior of a package changes.
Anytime the internal workings of a package change and your code is riddled with hacks that care about them, or you have poorly written tests that care about them.

Don't get hung up on test-first coding. It would make a well-d­esigned release much more estimable and consis­tent. But with a typical protot­ype­-be­com­es-­the­-pa­ckage, design as you go approach, re-writing tests before an initial public contract is finished can be a waste of time.

Enumerate and describe all of the public behaviors of your package.

Compro­mises:
Actual unit testing (stubbing out all services) results in sturdy tests that don't need to be re-written when depend­encies change. This results in a huge future payoff in reliab­ility and avoiding a cycle where code changes always necess­itate test changes (which is what test writing seems to be commonly perceived as).

In a time crunched situation it is possible to best-guess which services will actually change, and write integr­ation or partial integr­ation tests, but they should be marked as such, because it is essent­ially creating ongoing technical debt for whichever project they are placed in. It should not be more than a few minutes faster to write a throwaway test vs an actual unit test because there should be no need to create plumbing for any properly designed packages (thanks to sinonjs, systemjs, and the windsor test npm package).

test-j­s.git gets installed into the npm test command on the yeoman template automa­tic­ally. The npm test command looks up and runs tests in the lib directory. Tests are denoted as:
file.spec.js - Loaded with System.im­port, tested in node and browsers (allows es6)
file.web.s­pec.js - Loaded with System.im­port, tested in browsers (allows es6)
file.node.s­pec.js - Loaded with node's require(), tested in node (does not allow es6)