docs(angular): add faq with shallow rendering example (#1032)

Author: marcioggs

docs/angular-testing-library/faq.mdx

@@ -0,0 +1,107 @@
+---
+id: faq
+title: FAQ
+---
+
+See also the [main FAQ](dom-testing-library/faq.mdx) for questions not specific
+to Angular testing.
+
+<details>
+
+<summary>Can I write unit tests with this library?</summary>
+
+Definitely yes! You can write unit and integration tests with this library. See
+below for more on how to mock dependencies (because this library intentionally
+does NOT support shallow rendering) if you want to unit test a high level
+component. The tests in this project show several examples of unit testing with
+this library.
+
+As you write your tests, keep in mind:
+
+> The more your tests resemble the way your software is used, the more
+> confidence they can give you. - [17 Feb 2018][guiding-principle]
+
+</details>
+
+<details>
+
+<summary>
+  If I can't use shallow rendering, how do I mock out components in tests?
+</summary>
+
+In general, you should avoid mocking out components (see
+[the Guiding Principles section](guiding-principles.mdx)). However, if you need
+to, then try to use [ng-mocks](https://ng-mocks.sudo.eu/).
+
+```typescript
+import {Component, NgModule} from '@angular/core'
+import {render, screen} from '@testing-library/angular'
+import {ngMocks} from 'ng-mocks'
+
+@Component({
+  selector: 'app-parent-component',
+  template: '<app-child-component></app-child-component>',
+})
+class ParentComponent {}
+
+@Component({
+  selector: 'app-child-component',
+  template: '<p>Child component</p>',
+})
+class ChildComponent {}
+
+@NgModule({
+  declarations: [ParentComponent, ChildComponent],
+})
+export class AppModule {}
+
+describe('ParentComponent', () => {
+  it('should not render ChildComponent when shallow rendering', async () => {
+    const dependencies = ngMocks.guts(null, AppModule, ParentComponent)
+
+    await render(ParentComponent, dependencies)
+
+    expect(screen.queryByText('Child component')).toBeNull()
+  })
+})
+```
+
+</details>
+
+<details>
+
+<summary>
+  What level of a component tree should I test? Children, parents, or both?
+</summary>
+
+Following the guiding principle of this library, it is useful to break down how
+tests are organized around how the user experiences and interacts with
+application functionality rather than around specific components themselves. In
+some cases, for example for reusable component libraries, it might be useful to
+include developers in the list of users to test for and test each of the
+reusable components individually. Other times, the specific break down of a
+component tree is just an implementation detail and testing every component
+within that tree individually can cause issues (see
+https://kentcdodds.com/blog/avoid-the-test-user).
+
+In practice this means that it is often preferable to test high enough up the
+component tree to simulate realistic user interactions. The question of whether
+it is worth additionally testing at a higher or lower level on top of this comes
+down to a question of tradeoffs and what will provide enough value for the cost
+(see https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests on more info
+on different levels of testing).
+
+For a more in-depth discussion of this topic see
+[this video](https://youtu.be/0qmPdcV-rN8).
+
+</details>
+
+<!--
+Links:
+-->
+
+<!-- prettier-ignore-start -->
+
+[guiding-principle]: https://twitter.com/kentcdodds/status/977018512689455106
+
+<!-- prettier-ignore-end -->

sidebars.js

@@ -144,6 +144,7 @@ module.exports = {
             'angular-testing-library/intro',
             'angular-testing-library/examples',
             'angular-testing-library/api',
+            'angular-testing-library/faq',
           ],
         },
         {