This is great, Martin! So many examples say you should write the tests first, but then demonstrate how the framework works by writing the tests second.
Iām getting better at deciding which questions to ask/which pieces to test, but I would love to find more material on this topic. E.g., if I am going to use a shared module for all of my @angular/material components, what would I test for that module?
If you use it in all your components, it must handle cross cutting concerns like logging, data management, api access or something like that.
Especially in that case i would develop that module driven by tests more then ever. So i would start with an integration test for that module. Depending on the size and structure of the module, i would maybe break it down in smaller unit/component tests. But anyhow, i would always drive the development by tests.
For my liking the only reason not to test a component or module is that it is really humble and has no own behavior, like the views when using the "MVP Passive View"-pattern. Then, i think it is sufficient to only test it by e2e or system tests.
I think angular itself has a good guideline for testing (angular.io/guide/testing). And for TDD itself i love books about it from e.g. Uncle Bob and Kent Beck
šØāš« Co-Founder of This is Learning, Organizer of AarhusJS
āļø Writer, Speaker, FOSS Maintainer š Author
š Microsoft MVP š GitHub Star
š Nx Champion š¦ø Angular Hero of Education
We would import our shared MaterialModule in a TestBed with a declared TestComponent and verify that its template is able to render the Angular Material components that we expect the shared module to re-export.
This is great, Martin! So many examples say you should write the tests first, but then demonstrate how the framework works by writing the tests second.
Iām getting better at deciding which questions to ask/which pieces to test, but I would love to find more material on this topic. E.g., if I am going to use a shared module for all of my @angular/material components, what would I test for that module?
Thanks!
Thank you very much!
If you use it in all your components, it must handle cross cutting concerns like logging, data management, api access or something like that.
Especially in that case i would develop that module driven by tests more then ever. So i would start with an integration test for that module. Depending on the size and structure of the module, i would maybe break it down in smaller unit/component tests. But anyhow, i would always drive the development by tests.
For my liking the only reason not to test a component or module is that it is really humble and has no own behavior, like the views when using the "MVP Passive View"-pattern. Then, i think it is sufficient to only test it by e2e or system tests.
I think angular itself has a good guideline for testing (angular.io/guide/testing). And for TDD itself i love books about it from e.g. Uncle Bob and Kent Beck
Greets
We would import our shared MaterialModule in a TestBed with a declared TestComponent and verify that its template is able to render the Angular Material components that we expect the shared module to re-export.
Here is an example:
stackblitz.com/edit/ngx-module-tes...
Of course, you can do so.