1. Reuseability
Helper.js is a good thing to share code within a bundle - but not across many bundles. I think a strong library concept is still missing. Actually it's not possible to use CDN due to CSP but they are planning to introduce whitelists. It even looks like whitelists could be already possible:
Requesting CSP Exceptions
If your app is not working due to a CSP violation, contact Salesforce
to request a CSP exception for your org. Include the violation message
from your browser's developer console in any communication.
You can use Static Resources to provide libraries (package- or org-wide).
2. Testing
since it's very js-centric you might use some JS testing frameworks - but I expect salesforce to deliver here somthing.
3. Metadata / IDEs
All the Lightning metadata is available via Tooling API:
Alternatively access via Metadata API is working, too.
As far as I know, Force.com IDE still missing Lightning support. I think they are still on v30 or v31
You might also try a plugin for sublime/Mavensmate.
And CodeFusion actually does support Lightning since last year - however by design still without local files ;-)
But you need this package for lightning support - both, metadata and tooling API (v32) is supported.
I always planned to write a version control integration, but probably before that happens I'm going to open source the project.
A really cool thing about Lightning is the speed for saving files. It's not like apex or visualforce which needs about 3 to 10 seconds to save. Try saving a Lightning file it usually takes 0.300 to 0.800 seconds. First time fun coding! Doug's team unleashed a turbo here.
Some great questions here, and while I can't answer all of them, let me (a) answer what I can, and (b) make it clear that we're listening. :-)
First, though, keep in mind that the Lightning Testing Service as it's available today is a PILOT release. It's incomplete, we know there are known and unknown unknowns, etc. Feedback is key to shaping the direction that the LTS takes going forward. So keep it up!
A couple of answers.
(1.) We think that if your tests depend on actual responses to full Apex requests, they'll be "flappy", that is, bounce between success and failure, because you're testing too much in one test. Mock your Apex requests/responses, and test for the various possible responses. Test your Apex on the Apex side. (You have to do that anyway, for test coverage purposes, right?)
(4.) Coverage. Really good question. We don't have an answer for you today, beyond what's provided in e.g. Jasmine itself. It's going to be a while before we give you Apex-style coverage reports. Safe harbor, etc.
(7.) Lightning Component Builder wasn't a test UI, but a replacement for building components in the Developer Console. It was going to include new UI for tests, but the actual testing was going to be a separate feature. (Or so I've heard.)
In any event, the Lightning Component Builder as a specific tool is currently on hold. (If you're on the partner community, a few details here: https://partners.salesforce.com/0D53A000038fWzJ) We've got a huge overall tooling initiative going in the form of Salesforce DX, and will have a lot more to say about all of that throughout the year, especially at TrailheaDX and Dreamforce.
TrailheaDX is just two weeks away. If you're joining us there, please say hello to all the team members in attendance. We’re looking forward to meeting you, telling you more, and hearing what more we can do to make testing productive. (We know the list is long!)
Best Answer
LTS is a developer-focused function. I would think they will continue to manage it as an unmanaged package - easier to allow changes by developers. Numerous SFDC lab apps on AppExchange come to mind.