Repository navigation
Strawman for component-level testbed #1146
Description
It is very common for application developers to test their components with their templates. Internally we call these tests "component tests" (as opposed to unit- or integration-tests). These tests are not unit tests as they exercise more than just the component class. Nor are they integration tests as far as the application is concerned; that term is reserved for testing cross-component interactions, full application tests, and tests that involve the back-end.
Here are the requirements:
- instantiate a component in a test along with its template and child components
- replace child components with mocks
- pass bound values to the component
- trigger change detection
- fake the event loop, a la FakeAsync
- verify that component implement change detection correctly (e.g. via observables, immutables)
- access underlying DOM to trigger user events, such as click on buttons (this is usually done with the assistance of the Page Objects framework)
Strawman:
// This annotation tells Angular about test-specific dependency overrides
@ComponentTest(
component: MyComponent,
dependencyOverrides: const {
ChildComponent: MockChildComponent,
RealGoogleMap: MockGoogleMap,
}
)
main() {
describe("my-component", () {
TestBed<MyComponent> testBed;
beforeEach(() {
testBed = createTestBedFor(MyComponent);
});
it("should work as intended", fakeAsync(async) {
// instantiates a new component
MyComponent cmp = testBed.component();
// pass bindings using normal setters
cmp.field1 = "hello";
cmp.field2 = "world";
// detectChanges runs change detection and returns how many
// components ended up reevaluated, allowing testing correctness
// of change detection
expect(testBed.detectChanges().length, 5);
// emulate passage of time
async.flushMicrotasks();
async.elapse(seconds: 1);
// get access to the DOM
Element rootElem = testBed.element();
rootElem.querySelector('some-button').click();
expect(cmp.buttonClicked, true);
});
});
}Metadata
Metadata
Assignees
Labels
No labels
Activity
yjbanov commentedon Mar 27, 2015
/cc @matanlurey @jbdeboer @tbosch @mhevery @juliemr
matanlurey commentedon Mar 27, 2015
Apparently this may be partially covered by #615. But I'd like to keep this open if possible because the strawman above is what would ease migration.
[-]Provide component-level testbed[/-][+]Strawman for component-level testbed[/+]yjbanov commentedon Mar 27, 2015
/cc @vsavkin
yjbanov commentedon Mar 27, 2015
related: https://docs.google.com/document/d/1qFfHwYCOLpLuTap_l6TCEaU4I0C-pVFVbTl2o4-XbUo/edit#heading=h.aetfsm7ib2fe
naomiblack commentedon Mar 30, 2015
@vicb can you resolve this along with #615?
mhevery commentedon Apr 3, 2015
@yjbanov I think we need to discuss this. I think this should be done through
TestBedAPI rather than annotation. I am going to move it to later milestone for now.yjbanov commentedon Apr 3, 2015
@mhevery What would be the benefits of using imperative API over annotations?
mhevery commentedon Apr 4, 2015
Annotations are static. Imperative APIs can be easily extended, conditionally applied etc in the tests and even in the middle of the test.
yjbanov commentedon Apr 7, 2015
OTOH, imperative API shuts the door to any potential code generated approaches to DI as no static analysis can be done on it. Could you give any concrete examples that annotations would not support?
mhevery commentedon Apr 7, 2015
Not sure code generation is high priority for tests.
5 remaining items
yjbanov commentedon May 1, 2015
@mhevery the existing test bed API is based on internal classes and lacks integration with the event loop (specifically microtasks) and change detection.
@vicb what do you think of the above proposal? We need to start working on this asap. If you are blocked on something urgent, please we can reassign.
I'm ok with dropping the static API for the short term solution.
vicb commentedon May 4, 2015
@yjbanov I think most of the requested features are available (
fakeAsyncexcepted) via theTestBed.The priority right now should be to make the TestBed public (#1609) - might be a good idea to re-assign this item to someone with more bandwidth & who knows the render architecture better than I do.
I have been working a lot on zones lately (#1609). Once we come with a working solution for microtasks in JS/Dart (hopefully sometime this week), I'll resume the work on
fakeAsync()(as of today JS does not know what a microtask is which make it impossible tomicroleap() / flushMicrotasks())I also think we should first focus on the imperative API before starting to think about the static API.
We also need to instrument the CD to fully cover your proposal, I had created a separate issue: #1172
matanlurey commentedon May 6, 2015
I am looking into how Yegor's proposal could work, focusing on Dart. Will report back with any blockers.
vicb commentedon May 7, 2015
@matanlurey I'm working on
fakeAsyncATM (making sure we don't duplicate the effort)matanlurey commentedon May 7, 2015
I am just using the Dart (quiver/testing/async) library, which can be replaced by yours when it's ready.
vicb commentedon May 7, 2015
My plan is to use fake_async (Dart) and lolex (JS) and come with Dart & JS wrappers.
I think it will be easier now that JS zone also has a
scheduleMicrotaskmhevery commentedon May 8, 2015
I will work on this.
yjbanov commentedon May 12, 2015
This has been superseded by #1812. Closing.
angular-automatic-lock-bot commentedon Sep 6, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.