Skip to content

Commit 6ae8590

Browse files
committed
minor testing tweaks
1 parent 63c23ba commit 6ae8590

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

src/guide/scaling-up/testing.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -91,11 +91,11 @@ A component can be tested in two ways:
9191

9292
1. Whitebox: Unit Testing
9393

94-
Tests that are "Whitebox tests" are aware of the implementation details and dependencies of a component. They are focused on **isolating** the component under test. These tests will usually involve mocking some, if not all of your component's children, as well as setting up plugin state and dependencies (e.g. Vuex).
94+
Tests that are "Whitebox tests" are aware of the implementation details and dependencies of a component. They are focused on **isolating** the component under test. These tests will usually involve mocking some, if not all of your component's children, as well as setting up plugin state and dependencies (e.g. Vuex).
9595

9696
2. Blackbox: Component Testing
9797

98-
Tests that are "Blackbox tests" are unaware of the implementation details of a component. These tests mock as little as possible to test the integration of your component and the entire system. They usually render all child components and are considered more of an "integration test". See the [Component Testing recommendations](#component-testing) below.
98+
Tests that are "Blackbox tests" are unaware of the implementation details of a component. These tests mock as little as possible to test the integration of your component and the entire system. They usually render all child components and are considered more of an "integration test". See the [Component Testing recommendations](#component-testing) below.
9999

100100
### Recommendation
101101

@@ -128,9 +128,9 @@ Component tests should focus on the component's public interfaces rather than in
128128
- For **Visual** logic: assert correct render output based on inputted props and slots.
129129
- For **Behavioral** logic: assert correct render updates or emitted events in response to user input events.
130130

131-
In the below example, we demonstrate a Stepper component that has a DOM element labeled "increment" and can be clicked. We pass a prop called `max` that prevents the Stepper from being incremented past `2`, so if we click the button 3 times, the UI should still say `2`.
131+
In the below example, we demonstrate a Stepper component that has a DOM element labeled "increment" and can be clicked. We pass a prop called `max` that prevents the Stepper from being incremented past `2`, so if we click the button 3 times, the UI should still say `2`.
132132

133-
We know nothing about the implementation of Stepper, only that the "input" is the `max` prop and the "output" is the state of the DOM as the user will see it.
133+
We know nothing about the implementation of Stepper, only that the "input" is the `max` prop and the "output" is the state of the DOM as the user will see it.
134134

135135
<TestingApiSwitcher>
136136

@@ -203,11 +203,11 @@ cy.get(valueSelector).should('be.visible').and('contain.text', '0')
203203

204204
- **DON'T**
205205

206-
Assert the private state of a component instance or test the private methods of a component. Testing implementation details makes the tests brittle, as they are more likely to break and require updates when the implementation changes.
206+
Don't assert the private state of a component instance or test the private methods of a component. Testing implementation details makes the tests brittle, as they are more likely to break and require updates when the implementation changes.
207207

208208
The component's ultimate job is rendering the correct DOM output, so tests focusing on the DOM output provide the same level of correctness assurance (if not more) while being more robust and resilient to change.
209209

210-
Rely exclusively on snapshot tests. Asserting HTML strings does not describe correctness. Write tests with intentionality.
210+
Don't rely exclusively on snapshot tests. Asserting HTML strings does not describe correctness. Write tests with intentionality.
211211

212212
If a method needs to be tested thoroughly, consider extracting it into a standalone utility function and write a dedicated unit test for it. If it cannot be extracted cleanly, it may be tested as a part of a component, integration, or end-to-end test that covers it.
213213

0 commit comments

Comments
 (0)