honeymoose/angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: Rename FAQ to Useful Tips (#35316)

Browse Source 
Previously, a section in the FAQ was not clear when discussing a
simple unit test. We also want to move away from question-based
sections. This commit clarified the confusing section and
changed all question-based sections.

Closes #35056

PR Close #35316
This commit is contained in:
Sonu Kapoor 2020-02-10 21:03:36 -05:00 committed by Kara Erickson
parent f222bc1e30
commit 6091039223
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
aio/content/guide/testing.md
View File

@ -3582,13 +3582,13 @@ The Angular `By` class has three static methods for common predicates:
<hr> <hr>
{@a faq} {@a useful-tips}
## Frequently Asked Questions ## Useful tips
{@a q-spec-file-location} {@a q-spec-file-location}
#### Why put spec file next to the file it tests? #### Place your spec file next to the file it tests
It's a good idea to put unit test spec files in the same folder It's a good idea to put unit test spec files in the same folder
as the application source code files that they test: as the application source code files that they test:
@ -3599,11 +3599,9 @@ as the application source code files that they test:
- When you move the source (inevitable), you remember to move the test. - When you move the source (inevitable), you remember to move the test.
- When you rename the source file (inevitable), you remember to rename the test file. - When you rename the source file (inevitable), you remember to rename the test file.
<hr>
{@a q-specs-in-test-folder} {@a q-specs-in-test-folder}
#### When would I put specs in a test folder? #### Place your spec files in a test folder
Application integration specs can test the interactions of multiple parts Application integration specs can test the interactions of multiple parts
spread across folders and modules. spread across folders and modules.
@ -3615,15 +3613,17 @@ It's often better to create an appropriate folder for them in the `tests` direct
Of course specs that test the test helpers belong in the `test` folder, Of course specs that test the test helpers belong in the `test` folder,
next to their corresponding helper files. next to their corresponding helper files.
{@a q-e2e} {@a q-kiss}
#### Why not rely on E2E tests of DOM integration? #### Keep it simple
The component DOM tests described in this guide often require extensive setup and [Component class testing](#component-class-testing) should be kept very clean and simple.
advanced techniques whereas the [unit tests](#component-class-testing) It should test only a single unit. On a first glance, you should be able to understand
are comparatively simple. what the test is testing. If it's doing more, then it doesn't belong here.
#### Why not defer DOM integration tests to end-to-end (E2E) testing? {@a q-end-to-end}
#### Use E2E (end-to-end) to test more than a single unit
E2E tests are great for high-level validation of the entire system. E2E tests are great for high-level validation of the entire system.
But they can't give you the comprehensive test coverage that you'd expect from unit tests. But they can't give you the comprehensive test coverage that you'd expect from unit tests.