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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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