Merge unit / integration component tests

[thec0keman]

I know this has been raised several times, but I still wanted to open an issue to discuss it more.

With the addition of component integration tests we now have a great set of tools for testing components. Personally, I am strongly motivated to use as many components as possible since testing them is very easy and super fast. However, there are a couple of pain points:

• unit tests are very limited (as they should be)
• integration tests cannot access the component instance

This leads to an awkward choice between the two when what you really want is the best parts of both types of testing. There are alternatives, but it seems like we should be able to have our cake and eat it too. Simply exposing the component instance with this.subject() in integration tests would solve a lot:

• it allows for integration tests to mutate or test any component internals
• it allows for having unit tests that will see all of the component lifecycle hooks fire
• it simplifies the APIs for component tests

Outside of supporting existing tests, I'm not sure if there would even be a need for supporting the current implementation of unit tests. There are a couple of other changes that could help the transition (like having this.render() default to something like "{{ ${ component-name } }}" if no string is passed), but that seems secondary.

I'm sure the argument for this is something like you are crossing a conceptual boundary if you wanted both the setup / context of an integration test and the instance of a unit test, but is this necessary to enforce? Would it be sufficient to allow individual coders to be responsible for organizing their tests as unit / integration?

[Turbo87]

this is going to be covered by emberjs/rfcs#232