We should write tests to cover smaller pieces of code, stubbing functions out when necessary. We could use proxyquire or stub methods out manually in the tests themselves. Currently our tests are generally functional & smoke tests, which are good, but don't provide the kind of coverage that I think would be nice to have.
Tests like these can also help make npm more modular, as it will be much easier to write these tests with more pieces of npm broken out into individual modules.
+1. This is a large part of why I broke out such a trivial feature as path-is-inside into its own package in 966373f: because npm didn't seem set up for unit tests, and so I wanted my own project that could do the level of deep unit-level testing I am used to.
This is a fantastic idea and something that I very much want to see happen, but oh my gosh is it a lot of work. We've been breaking off little pieces to write unit tests for, and have been introducing the use of tools like tacks and require-inject to simplify the process of getting around how tightly-scoped business logic is to CLI scaffolding, but a comprehensive fix of this requires that we remove the use of a global config object and that the CLI's internal API be redesigned.
The only way this is going to happen in incremental pieces, so I'm putting the patch-welcome label on it. Anyone who wants to knock down a few unit tests, no matter how small, will be acknowledged with gratitude by the CLI team. I would feel much better about the quality of the CLI if I knew that we had meaningful unit test coverage.