116 | );
117 | }
118 | });
119 |
120 | global.TodoItem = TodoItem;
121 | global.TodoList = TodoList;
122 | global.App = App;
123 |
124 | const MyButton = createClass({
125 | displayName: 'MyButton',
126 | getInitialState () {
127 | return {
128 | count: 0
129 | };
130 | },
131 |
132 | onClick () {
133 | const { count } = this.state;
134 | this.setState({ count: count + 1 });
135 | },
136 |
137 | render() {
138 | const { count } = this.state;
139 |
140 | return (
141 |
144 | );
145 | }
146 | });
147 |
148 | global.MyButton = MyButton;
149 |
--------------------------------------------------------------------------------
/demo/1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/bruderstein/unexpected-react/e7cbb1a00de5b413147af96761007b45ec08b88f/demo/1.png
--------------------------------------------------------------------------------
/demo/2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/bruderstein/unexpected-react/e7cbb1a00de5b413147af96761007b45ec08b88f/demo/2.png
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/queried-for.md:
--------------------------------------------------------------------------------
1 | This enables finding a particular component or element, to then perform further assertions on.
2 |
3 | e.g.
4 | ```js
5 | var renderer = createRenderer()
6 | renderer.render(
7 |
8 |
9 |
10 |
11 |
12 | );
13 |
14 | expect(
15 | renderer, 'queried for',
16 | ,
17 | 'to have rendered',
18 |
19 | );
20 | ```
21 |
22 | Here the `TodoList` component is rendering a list of todo items. Here we're
23 | querying for the todo item with the id 3 and then we check that it has the
24 | expected text. This example show how you only mention exactly what you are
25 | searching for. If the assertion finds a match it is forwarded to the next
26 | assertion; otherwise it fails with a helpful message.
27 |
28 | You can use `to have rendered` or `to contain` with all the options as usual following a `queried for`.
29 |
30 |
31 | It is possible to use `queried for` to extract a part of a component.
32 |
33 | ```js#async:true
34 | return expect(renderer, 'queried for', )
35 | .then(todoItem => {
36 | expect(todoItem.props.label, 'to equal', 'Buy groceries');
37 | });
38 | ```
39 |
40 | Note that it is not possible to call an event using `with event` after using `queried for` in
41 | an assertion. This is because the `queried for` extracts the rendered output from the shallow
42 | renderer, so future events will be lost.
43 |
44 | ## queryTarget
45 |
46 | If you want to find a target nested inside a parent element, use `queryTarget` in the query.
47 | e.g. This `queried for` clause returns the `input` element inside the `div` with
48 | the class `add-new-item`.
49 |
50 | ```js
51 | expect(renderer, 'queried for', ,
52 | 'to have rendered', );
53 | ```
54 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/to-contain.md:
--------------------------------------------------------------------------------
1 | It's possible to check for a part of the subtree, without
2 | testing the entire returned tree. This allows you to test specific elements, without
3 | writing brittle tests that break when the structure changes.
4 |
5 | Assuming the following component output
6 | ```js
7 | const MyComponent = () => (
8 |
9 | one
10 | two
11 | three
12 |
13 | )
14 |
15 | var renderer = createRenderer()
16 | renderer.render()
17 | ```
18 |
19 | ```js
20 | // This will pass, as `two` can be found in the renderers output
21 | expect(renderer, 'to contain', two);
22 | ```
23 |
24 | Notice that the extra `className="middle"` in the `two` is ignored,
25 | in a similar way to the `to have rendered` assertion.
26 |
27 | You can override this behaviour by using `'to contain exactly'`, and `'to contain with all children'`
28 |
29 |
30 | ```js
31 | // This will fail, as `two` cannot be found in the renderers output, due to
32 | // the missing `className="middle"` prop
33 | expect(renderer, 'to contain exactly', two);
34 | ```
35 |
36 | ```output
37 | expected
38 |
39 | one
40 | two
41 | three
42 |
43 | to contain exactly two
44 |
45 | the best match was
46 |
48 | two
49 |
50 | ```
51 |
52 | The same thing applies to children for `'to contain'` as for `'to have rendered'`.
53 |
54 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/to-deeply-render-as.md:
--------------------------------------------------------------------------------
1 | Given the following test component:
2 |
3 | ```js
4 | const MyComponent = () => (
5 |
6 | one
7 | two
8 | three
9 |
10 | )
11 | ```
12 |
13 | You can validate the rendering of this component with the `to deeply render as` assertion,
14 | which renders the component using the full virtual DOM renderer, and validates the output.
15 |
16 | ```js
17 | expect(, 'to deeply render as', );
18 | ```
19 |
20 | This works using the same rules as `to have rendered`, but saves you using the TestUtils
21 | and `renderIntoDocument()` or using `ReactDOM.render(...)` directly when you just want to
22 | validate some translation of props to output.
23 |
24 | ```js
25 | // The span "two" is missing here, but it is ignored.
26 | expect(, 'to render as',
27 |
28 | one
29 | three
30 |
31 | );
32 | ```
33 |
34 | ```js
35 | // The following assertion will fail, as 'four' does not exist
36 | expect(, 'to render as',
37 |
38 | one
39 | four
40 |
41 | );
42 | ```
43 |
44 | ```output
45 | expected
46 | to render as
onefour
47 |
48 |
49 | one
50 |
51 | two // -two
52 | // +four
53 |
54 | three
55 |
56 | ```
57 |
58 | If you want to check for an exact render, use `'to exactly deeply render as'`.
59 |
60 | Alternatively, if you don't care about extra props, but want to check that there are no extra child nodes, use `'to have rendered with all children'`
61 | Note that `exactly` implies `with all children`, so you using both options is not necessary.
62 |
63 | Normally wrappers (elements that simply wrap other components) are ignored. This can be useful if you have higher order
64 | components wrapping your components, you can simply ignore them in your tests (they will be shown greyed out
65 | if there is a "real" error). If you want to test that there are no extra wrappers, simply add
66 | `with all wrappers` to the assertion.
67 |
68 |
69 | ```js
70 | // The span "two" is missing here, as is `className="parent"`
71 | // The missing span will cause an assertion error, but the extra prop will be ignored
72 | // due to `to have rendered with all children` being used
73 |
74 | expect(, 'to deeply render with all children as',
75 |
76 | one
77 | three
78 |
79 | );
80 | ```
81 |
82 | ```output
83 | expected
84 | to deeply render with all children as
onethree
85 |
86 |
87 |
88 | one
89 | two // should be removed
90 | three
91 |
92 |
93 | ```
94 |
95 | ```js
96 | // The span "two" is missing here, as is `className="parent"`
97 | // This will cause an assertion error,
98 | // due to `to have exactly rendered` being used
99 |
100 | expect(, 'to exactly deeply render as',
101 |
102 |
117 | one
118 | two // should be removed
119 | three
120 |
121 |
122 | ```
123 |
124 | If you want to trigger events, use the `when deeply rendered` assertion to render
125 | the component, then use the other `with event` and `to have rendered` or `to contain`
126 | assertions to validate the output.
127 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/to-have-rendered.md:
--------------------------------------------------------------------------------
1 | Given the following test component:
2 |
3 | ```js
4 | const MyComponent = () => (
5 |
6 | one
7 | two
8 | three
9 |
10 | )
11 | ```
12 |
13 | Let's render the output with the shallow renderer:
14 |
15 | ```js
16 | const renderer = createRenderer();
17 | renderer.render();
18 | ```
19 |
20 | ```js
21 | // Extra props and children from the render are ignored
22 | expect(renderer, 'to have rendered', );
23 | ```
24 |
25 | ```js
26 | // The span "two" is missing here, but it is ignored.
27 | expect(renderer, 'to have rendered',
28 |
29 | one
30 | three
31 |
32 | );
33 | ```
34 |
35 | ```js
36 | // The following assertion will fail, as 'four' does not exist
37 | expect(renderer, 'to have rendered',
38 |
53 | one
54 |
55 | two // -two
56 | // +four
57 |
58 | three
59 |
60 | ```
61 |
62 | If you want to check for an exact render, use `'to have exactly rendered'`.
63 |
64 | Alternatively, if you don't care about extra props, but want to check that there are no extra child nodes, use `'to have rendered with all children'`
65 | Note that `exactly` implies `with all children`, so you using both options is not necessary.
66 |
67 | Normally wrappers (elements that simply wrap other components) are ignored. This can be useful if you have higher order
68 | components wrapping your components, you can simply ignore them in your tests (they will be shown greyed out
69 | if there is a "real" error). If you want to test that there are no extra wrappers, simply add
70 | `with all wrappers` to the assertion.
71 |
72 |
73 | ```js
74 | // The span "two" is missing here, as is `className="parent"`
75 | // The missing span will cause an assertion error, but the extra prop will be ignored
76 | // due to `to have rendered with all children` being used
77 |
78 | expect(renderer, 'to have rendered with all children',
79 |
94 | one
95 | two // should be removed
96 | three
97 |
98 | ```
99 |
100 | ```js
101 | // The span "two" is missing here, as is `className="parent"`
102 | // This will cause an assertion error,
103 | // due to `to have exactly rendered` being used
104 |
105 | expect(renderer, 'to have exactly rendered',
106 |
122 | one
123 | two // should be removed
124 | three
125 |
126 | ```
127 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/to-match-snapshot.md:
--------------------------------------------------------------------------------
1 | Under [jest](https://facebook.github.io/jest/), you can use snapshots. Snapshot tests save a snapshot of the component as it is currently rendered to a `.snapshot` file under a directory `__snapshots__`. Note that the snapshots for `unexpected-react` are saved to a different filename than those jest uses natively. This is because the format differs slightly.
2 |
3 | Remember that to include snapshot support for the shallow and DOM renderers, you need to require unexpected-react as `require('unexpected-react/jest')`
4 |
5 | Given the following test component:
6 |
7 | ```js
8 | const MyComponent = () => (
9 |
10 | one
11 | two
12 | three
13 |
14 | )
15 | ```
16 |
17 | Let's render the output with the shallow renderer:
18 |
19 | ```js
20 | var renderer = createRenderer();
21 | renderer.render();
22 | ```
23 |
24 | Then we can validate it matches the snapshot. If no snapshot exists, it will be automatically created the first time it is run.
25 |
26 | ```js#evaluate:false
27 | expect(renderer, 'to match snapshot');
28 | ```
29 |
30 | If in the future the component output changes, the error will be highlighted (using the same error highlighting used in the rest of unexpected-react).
31 |
32 | Once you have checked that the changes are correct, you can run `jest -u` to update the snapshot, or if running in watch mode, press `u`.
33 |
34 | ### Events
35 | Triggered events still works, and can be combined with matching snaphots.
36 |
37 | e.g.
38 |
39 | ```js#evaluate:false
40 | var renderer = createRenderer();
41 | renderer.render();
42 |
43 | expect(renderer,
44 | 'with event click',
45 | 'to match snapshot'
46 | );
47 | ```
48 |
49 |
50 | ### Matching
51 |
52 | The snapshot matches everything, so extra classes and attributes will causes a difference to be highlighted. If you want your snapshots to work more like `to have rendered`, so new attributes, classes and child elements can be added without triggering a change, see the assertion `to satisfy snapshot`.
53 |
54 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/to-render-as.md:
--------------------------------------------------------------------------------
1 | Given the following test component:
2 |
3 | ```js
4 | const MyComponent = () => (
5 |
6 | one
7 | two
8 | three
9 |
10 | )
11 | ```
12 |
13 | You can validate the rendering of this component with the `to render as` assertion,
14 | which renders the component to a new shallow renderer, and validates the output.
15 |
16 | ```js
17 | expect(, 'to render as', );
18 | ```
19 |
20 | This works using the same rules as `to have rendered`, but saves you creating a
21 | new shallow renderer when you just want to validate some translation of props to
22 | output.
23 |
24 | ```js
25 | // The span "two" is missing here, but it is ignored.
26 | expect(, 'to render as',
27 |
28 | one
29 | three
30 |
31 | );
32 | ```
33 |
34 | ```js
35 | // The following assertion will fail, as 'four' does not exist
36 | expect(, 'to render as',
37 |
38 | one
39 | four
40 |
41 | );
42 | ```
43 |
44 | ```output
45 | expected
46 | to render as
onefour
47 |
48 |
49 | one
50 |
51 | two // -two
52 | // +four
53 |
54 | three
55 |
56 | ```
57 |
58 | If you want to check for an exact render, use `'to exactly render as'`.
59 |
60 | Alternatively, if you don't care about extra props, but want to check that there are no extra child nodes, use `'to have rendered with all children'`
61 | Note that `exactly` implies `with all children`, so you using both options is not necessary.
62 |
63 | Normally wrappers (elements that simply wrap other components) are ignored. This can be useful if you have higher order
64 | components wrapping your components, you can simply ignore them in your tests (they will be shown greyed out
65 | if there is a "real" error). If you want to test that there are no extra wrappers, simply add
66 | `with all wrappers` to the assertion.
67 |
68 |
69 | ```js
70 | // The span "two" is missing here, as is `className="parent"`
71 | // The missing span will cause an assertion error, but the extra prop will be ignored
72 | // due to `to have rendered with all children` being used
73 |
74 | expect(, 'to render with all children as',
75 |
76 | one
77 | three
78 |
79 | );
80 | ```
81 |
82 | ```output
83 | expected
84 | to render with all children as
onethree
85 |
86 |
87 | one
88 | two // should be removed
89 | three
90 |
91 | ```
92 |
93 | ```js
94 | // The span "two" is missing here, as is `className="parent"`
95 | // This will cause an assertion error,
96 | // due to `to have exactly rendered` being used
97 |
98 | expect(, 'to exactly render as',
99 |
100 | one
101 | three
102 |
103 | );
104 | ```
105 |
106 | ```output
107 | expected
108 | to exactly render as
onethree
109 |
110 |
112 | one
113 | two // should be removed
114 | three
115 |
116 | ```
117 |
118 | If you want to trigger events, use the `when rendered` assertion to render
119 | the component, then use the other `with event` and `to have rendered` or `to contain`
120 | assertions to validate the output.
121 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/to-satisfy-snapshot.md:
--------------------------------------------------------------------------------
1 | Under [jest](https://facebook.github.io/jest/), you can use snapshots. Snapshot tests save a snapshot of the component as it is currently rendered to a `.snapshot` file under a directory `__snapshots__`. Note that the snapshots for `unexpected-react` are saved to a different filename than those jest uses natively. This is because the format differs slightly.
2 |
3 | Remember that to include snapshot support for the shallow and DOM renderers, you need to require unexpected-react as `require('unexpected-react/jest')`
4 |
5 | Given the following test component:
6 |
7 | ```js
8 | var MyComponent = () => (
9 |
10 | one
11 | two
12 | three
13 |
14 | )
15 | ```
16 |
17 | Let's render the output with the shallow renderer:
18 |
19 | ```js
20 | var renderer = createRenderer();
21 | renderer.render();
22 | ```
23 |
24 | Then we can validate it matches the snapshot. If no snapshot exists, it will be automatically created the first time it is run.
25 |
26 | ```js#evaluate:false
27 | expect(renderer, 'to satisfy snapshot');
28 | ```
29 |
30 | If in the future the component output changes, the error will be highlighted (using the same error highlighting used in the rest of unexpected-react).
31 |
32 | Once you have checked that the changes are correct, you can run `jest -u` to update the snapshot, or if running in watch mode, press `u`.
33 |
34 | ### Events
35 | Triggered events still works, and can be combined with matching snaphots.
36 |
37 | e.g.
38 |
39 | ```js#evaluate:false
40 | var renderer = createRenderer();
41 | renderer.render();
42 |
43 | expect(renderer,
44 | 'with event click',
45 | 'to satisfy snapshot'
46 | );
47 | ```
48 |
49 | ### Matching
50 |
51 | The snapshot matches in the same way as `to have rendered`, so new classes, attributes and child nodes are not treated as a difference. This can be advantageous when you want to add new features to a component, but expect the existing component to keep the same basic template.
52 |
53 | If you'd prefer to match the template exactly (order of classes is still ignored), see the assertion `to match snapshot`.
54 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/when-deeply-rendered.md:
--------------------------------------------------------------------------------
1 |
2 | You can render a component with the full DOM renderer directly with the `when deeply rendered` assertion.
3 |
4 | This works with both stateful and stateless (functional) components, which can be easier than creating a manual wrapper and manually rendering into the DOM with `TestUtils.renderIntoDocument(...)` or `ReactDOM.render(...)`
5 |
6 | Say you have these components:
7 | ```js
8 |
9 | const Page = (props) => Page {props.page};
10 |
11 | const Pages = (props) => {
12 | const pageElements = [];
13 | for (let i = 1; i <= props.count; ++i) {
14 | pageElements.push();
15 | }
16 | return (
17 |
18 | {pageElements}
19 |
20 | );
21 | };
22 |
23 | ```
24 |
25 | You can check the rendering directly using the `when deeply rendered` assertion, saving you from creating stateless wrappers and rendering into the DOM by hand:
26 | ```js
27 | expect(,
28 | 'when deeply rendered',
29 | 'to have rendered',
30 |
35 | );
36 | ```
37 |
38 | Everything works after the `when deeply rendered`, so you can use events and all the other assertions as normal
39 | ```js
40 | expect(,
41 | 'when deeply rendered',
42 | 'with event', 'click',
43 | 'to have rendered',
44 |
45 | );
46 | ```
47 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/when-rendered.md:
--------------------------------------------------------------------------------
1 |
2 | You can render a component with the shallow renderer directly with the `when rendered` assertion.
3 |
4 | Say you have this component:
5 | ```js
6 | const Pages = (props) => {
7 | const pageElements = [];
8 | for (let i = 1; i <= props.count; ++i) {
9 | pageElements.push(Page {i});
10 | }
11 | return (
12 |
13 | {pageElements}
14 |
15 | );
16 | };
17 |
18 | ```
19 |
20 | You can check the rendering directly using the `when rendered` assertion, saving you from creating the shallow renderer by hand:
21 | ```js
22 | expect(,
23 | 'when rendered',
24 | 'to have rendered',
25 |
30 | );
31 | ```
32 |
33 | Everything works after the `when rendered` as normal, so you can trigger events and use the other assertions as you would otherwise.
34 | ```js
35 | expect(,
36 | 'when rendered',
37 | 'with event', 'click',
38 | 'to have rendered',
39 |
40 | );
41 | ```
42 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactElement/with-event.md:
--------------------------------------------------------------------------------
1 | ## `with event` .... [`on`]
2 |
3 | `with event` can trigger events in both the shallow and full renderer. For the normal full renderer,
4 | `TestUtils.Simulate` is used to simulate the event. For the shallow renderer, it is expected that
5 | there is a prop with the name `on[EventName]`, where the first letter of the event is capitalised.
6 |
7 | e.g. with a button that counts it's own clicks
8 |
9 | ```js
10 | var renderer = createRenderer()
11 | renderer.render();
12 |
13 | expect(renderer, 'with event', 'click', 'to have rendered', );
14 | ```
15 |
16 | This works with the component directly, as a shallow renderer is automatically created.
17 | Also note that due to unexpected's clever string handling, you can concatenated the `with event` and the
18 | event name.
19 |
20 |
21 | ```js
22 | expect(, 'with event click', 'to have rendered', );
23 | ```
24 |
25 | Given the following todo list:
26 |
27 | ```js
28 | var renderer = createRenderer()
29 | renderer.render(
30 |
31 |
32 |
33 |
34 |
35 | );
36 | ```
37 |
38 | If you want to trigger an event on a specific component, (i.e. not the top level component), use `on`
39 | after the event.
40 |
41 | ```js
42 | expect(
43 | renderer,
44 | 'with event click',
45 | 'on', ,
46 | 'to contain',
47 | );
48 | ```
49 |
50 | To pass arguments to the event, simply include the event object after the event name
51 |
52 | ```js
53 | expect(
54 | renderer,
55 | 'with event mouseDown', { mouseX: 150, mouseY: 50 },
56 | 'on', ,
57 | 'to contain',
58 | );
59 | ```
60 |
61 | This will call the function passed in the `onMouseDown` prop of the ``.
62 |
63 |
64 |
65 | You can take the renderer after the event has been triggered by using the promise returned
66 | from `expect`. This is often used to test that spy or mock callbacks have been called (using for instance [sinon.js](http://sinonjs.org)).
67 |
68 | ```js#async:true
69 | return expect(
70 | renderer,
71 | 'with event click', 'on',
72 | ).then(renderer => {
73 | const todoListInstance = renderer.getMountedInstance();
74 | expect(todoListInstance.state, 'to satisfy', { clicked: { 2: true } });
75 | });
76 |
77 | ```
78 |
79 | ## eventTarget
80 |
81 | You can add an `eventTarget` prop to the expected to trigger the event on a child component.
82 | e.g.
83 | ```js
84 | var renderer = createRenderer()
85 | renderer.render();
86 |
87 | expect(renderer,
88 | 'with event', 'click', 'on', ,
89 | 'to have rendered',
90 |
91 |
92 |
93 |
);
94 | ```
95 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactTestRenderer/queried-for.md:
--------------------------------------------------------------------------------
1 | This enables finding a particular component or element, to then perform further assertions on.
2 |
3 | e.g.
4 | ```js
5 | var TestRenderer = require('react-test-renderer');
6 | var renderer = TestRenderer.create(
7 |
8 |
9 |
10 |
11 |
12 | );
13 |
14 | expect(
15 | renderer, 'queried for',
16 | ,
17 | 'to have rendered',
18 |
19 | Buy groceries
20 |
21 | );
22 | ```
23 |
24 | Here the `TodoList` component is rendering a list of todo items. Here we're
25 | querying for the todo item with the id 3 and then we check that it has the
26 | expected text. This example show how you only mention exactly what you are
27 | searching for. If the assertion finds a match it is forwarded to the next
28 | assertion; otherwise it fails with a helpful message.
29 |
30 | You can use `to have rendered` or `to contain` with all the options as usual following a `queried for`.
31 |
32 | ## queryTarget
33 |
34 | If you want to find a target nested inside a parent element, use `queryTarget` in the query.
35 | e.g. This `queried for` clause returns the `input` element inside the `div` with
36 | the class `add-new-item`.
37 |
38 | ```js
39 | expect(renderer, 'queried for', ,
40 | 'to have rendered', );
41 | ```
42 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactTestRenderer/to-contain.md:
--------------------------------------------------------------------------------
1 | It's possible to check for a part of the subtree, without
2 | testing the entire returned tree. This allows you to test specific elements, without
3 | writing brittle tests that break when the structure changes.
4 |
5 | Assuming the following component output
6 | ```js
7 | const MyComponent = () => (
8 |
9 | one
10 | two
11 | three
12 |
13 | )
14 |
15 | var renderer = TestRenderer.create();
16 | ```
17 |
18 | ```js
19 | // This will pass, as `two` can be found in the renderers output
20 | expect(renderer, 'to contain', two);
21 | ```
22 |
23 | Notice that the extra `className="middle"` in the `two` is ignored,
24 | in a similar way to the `to have rendered` assertion.
25 |
26 | You can override this behaviour by using `'to contain exactly'`, and `'to contain with all children'`
27 |
28 |
29 | ```js
30 | // This will fail, as `two` cannot be found in the renderers output, due to
31 | // the missing `className="middle"` prop
32 | expect(renderer, 'to contain exactly', two);
33 | ```
34 |
35 | ```output
36 | expected
37 |
38 | one
39 | two
40 | three
41 |
42 | to contain exactly two
43 |
44 | the best match was
45 |
47 | two
48 |
49 | ```
50 |
51 | The same thing applies to children for `'to contain'` as for `'to have rendered'`.
52 |
53 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactTestRenderer/to-have-rendered.md:
--------------------------------------------------------------------------------
1 | Given the following test component:
2 |
3 | ```js
4 | const MyComponent = () => (
5 |
6 | one
7 | two
8 | three
9 |
10 | )
11 | ```
12 |
13 | Let's render the output with the test renderer:
14 |
15 | ```js
16 | const renderer = TestRenderer.create();
17 | ```
18 |
19 | ```js
20 | // Extra props and children from the render are ignored
21 | expect(renderer, 'to have rendered', );
22 | ```
23 |
24 | ```js
25 | // The span "two" is missing here, but it is ignored.
26 | expect(renderer, 'to have rendered',
27 |
28 | one
29 | three
30 |
31 | );
32 | ```
33 |
34 | ```js
35 | // The following assertion will fail, as 'four' does not exist
36 | expect(renderer, 'to have rendered',
37 |
52 | one
53 |
54 | two // -two
55 | // +four
56 |
57 | three
58 |
59 | ```
60 |
61 | If you want to check for an exact render, use `'to have exactly rendered'`.
62 |
63 | Alternatively, if you don't care about extra props, but want to check that there are no extra child nodes, use `'to have rendered with all children'`
64 | Note that `exactly` implies `with all children`, so you using both options is not necessary.
65 |
66 | Normally wrappers (elements that simply wrap other components) are ignored. This can be useful if you have higher order
67 | components wrapping your components, you can simply ignore them in your tests (they will be shown greyed out
68 | if there is a "real" error). If you want to test that there are no extra wrappers, simply add
69 | `with all wrappers` to the assertion.
70 |
71 |
72 | ```js
73 | // The span "two" is missing here, as is `className="parent"`
74 | // The missing span will cause an assertion error, but the extra prop will be ignored
75 | // due to `to have rendered with all children` being used
76 |
77 | expect(renderer, 'to have rendered with all children',
78 |
93 | one
94 | two // should be removed
95 | three
96 |
97 | ```
98 |
99 | ```js
100 | // The span "two" is missing here, as is `className="parent"`
101 | // This will cause an assertion error,
102 | // due to `to have exactly rendered` being used
103 |
104 | expect(renderer, 'to have exactly rendered',
105 |
121 | one
122 | two // should be removed
123 | three
124 |
125 | ```
126 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactTestRenderer/to-match-snapshot.md:
--------------------------------------------------------------------------------
1 | Under [jest](https://facebook.github.io/jest/), you can use snapshots. Snapshot tests save a snapshot of the component as it is currently rendered to a `.snapshot` file under a directory `__snapshots__`. Note that the snapshots for `unexpected-react` are saved to a different filename than those jest uses natively. This is because the format differs slightly.
2 |
3 | Remember that to include snapshot support for the test renderer, you need to require unexpected-react as `require('unexpected-react/test-renderer-jest')`
4 |
5 | Given the following test component:
6 |
7 | ```js
8 | const MyComponent = () => (
9 |
10 | one
11 | two
12 | three
13 |
14 | )
15 | ```
16 |
17 | Let's render the output with the test renderer:
18 |
19 | ```js
20 | const renderer = TestRenderer.create();
21 | ```
22 |
23 | Then we can validate it matches the snapshot. If no snapshot exists, it will be automatically created the first time it is run.
24 |
25 | ```js#evaluate:false
26 | expect(renderer, 'to match snapshot');
27 | ```
28 |
29 | If in the future the component output changes, the error will be highlighted (using the same error highlighting used in the rest of unexpected-react).
30 |
31 | Once you have checked that the changes are correct, you can run `jest -u` to update the snapshot, or if running in watch mode, press `u`.
32 |
33 | ### Events
34 | Triggered events still works, and can be combined with matching snaphots.
35 |
36 | e.g.
37 |
38 | ```js#evaluate:false
39 | const renderer = TestRenderer.create();
40 |
41 | expect(renderer,
42 | 'with event click',
43 | 'to match snapshot'
44 | );
45 | ```
46 |
47 | ### Matching
48 |
49 | The snapshot matches everything, so extra classes and attributes will causes a difference to be highlighted. If you want your snapshots to work more like `to have rendered`, so new attributes, classes and child elements can be added without triggering a change, see the assertion `to satisfy snapshot`.
50 |
51 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactTestRenderer/to-satisfy-snapshot.md:
--------------------------------------------------------------------------------
1 | Under [jest](https://facebook.github.io/jest/), you can use snapshots. Snapshot tests save a snapshot of the component as it is currently rendered to a `.snapshot` file under a directory `__snapshots__`. Note that the snapshots for `unexpected-react` are saved to a different filename than those jest uses natively. This is because the format differs slightly.
2 |
3 | Remember that to include snapshot support for the test renderer, you need to require unexpected-react as `require('unexpected-react/test-renderer-jest')`
4 |
5 | Given the following test component:
6 |
7 | ```js
8 | const MyComponent = () => (
9 |
10 | one
11 | two
12 | three
13 |
14 | )
15 | ```
16 |
17 | Let's render the output with the test renderer:
18 |
19 | ```js
20 | var renderer = TestRenderer.create();
21 | ```
22 |
23 | Then we can validate it matches the snapshot. If no snapshot exists, it will be automatically created the first time it is run.
24 |
25 | ```js#evaluate:false
26 | expect(renderer, 'to satisfy snapshot');
27 | ```
28 |
29 | If in the future the component output changes, the error will be highlighted (using the same error highlighting used in the rest of unexpected-react).
30 |
31 | Once you have checked that the changes are correct, you can run `jest -u` to update the snapshot, or if running in watch mode, press `u`.
32 |
33 | ### Events
34 | Triggered events still works, and can be combined with matching snaphots.
35 |
36 | e.g.
37 |
38 | ```js#evaluate:false
39 | var renderer = TestRenderer.create();
40 |
41 | expect(renderer,
42 | 'with event click',
43 | 'to satisfy snapshot'
44 | );
45 | ```
46 |
47 | ### Matching
48 |
49 | The snapshot matches in the same way as `to have rendered`, so new classes, attributes and child nodes are not treated as a difference. This can be advantageous when you want to add new features to a component, but expect the existing component to keep the same basic template.
50 |
51 | If you'd prefer to match the template exactly (order of classes is still ignored), see the assertion `to match snapshot`.
52 |
--------------------------------------------------------------------------------
/documentation/assertions/ReactTestRenderer/with-event.md:
--------------------------------------------------------------------------------
1 | ## `with event` .... [`on`]
2 |
3 | `with event` can trigger events in the shallow, full and test renderers. For the normal full renderer,
4 | `TestUtils.Simulate` is used to simulate the event. For the shallow and test renderers, it is expected that
5 | there is a prop with the name `on[EventName]`, where the first letter of the event is capitalised.
6 |
7 | e.g. with a button that counts its own clicks
8 |
9 | ```js
10 | var renderer = TestRenderer.create()
11 |
12 | expect(renderer, 'with event', 'click', 'to have rendered', );
13 | ```
14 |
15 | Also note that due to unexpected's clever string handling, you can often concatenate the `with event` and the
16 | event name.
17 |
18 | Given the following todo list:
19 |
20 | ```js
21 | var renderer = TestRenderer.create(
22 |
23 |
24 |
25 |
26 |
27 | );
28 | ```
29 |
30 | If you want to trigger an event on a specific component, (i.e. not the top level component), use `on`
31 | after the event.
32 |
33 | ```js
34 | expect(
35 | renderer,
36 | 'with event click', 'on', ,
37 | 'to contain',
Completed!
38 | );
39 | ```
40 |
41 | To pass arguments to the event, simply include the event object after the event name
42 |
43 | ```js
44 | expect(
45 | renderer,
46 | 'with event mouseDown', { mouseX: 150, mouseY: 50 },
47 | 'on', ,
48 | 'not to contain',
Completed!
49 | );
50 | ```
51 |
52 | This will call the function passed in the `onMouseDown` prop of the ``.
53 |
54 |
55 | You can take the renderer after the event has been triggered by using the promise returned
56 | from `expect`. This is often used to test that spy or mock callbacks have been called (using for instance [sinon.js](http://sinonjs.org)).
57 |
58 | ```js
59 | expect(
60 | renderer,
61 | 'with event click', 'on',
62 | );
63 | ```
64 |
65 | ```js#async:true
66 | return expect(
67 | renderer,
68 | 'with event click', 'on',
69 | ).then(function (renderer) {
70 | var todoListInstance = renderer.getInstance();
71 | expect(todoListInstance.state, 'to satisfy', { clicked: { 2: true } });
72 | });
73 |
74 | ```
75 |
76 | ## eventTarget
77 |
78 | You can add an `eventTarget` prop to the expected to trigger the event on a child component.
79 | e.g.
80 | ```js
81 | var renderer = TestRenderer.create();
82 |
83 | expect(renderer,
84 | 'with event', 'click', 'on', ,
85 | 'to have rendered',
86 |
87 |
88 |
89 |
);
90 | ```
91 |
--------------------------------------------------------------------------------
/documentation/assertions/RenderedReactElement/queried-for.md:
--------------------------------------------------------------------------------
1 | This enables finding a particular component or element, to then perform further assertions on.
2 |
3 | e.g.
4 | ```js
5 |
6 | var component = TestUtils.renderIntoDocument(
7 |
8 |
9 |
10 |
11 |
12 | );
13 |
14 | expect(
15 | component,
16 | 'queried for',
17 |
18 | 3
19 |
,
20 | 'to have rendered',
21 |
22 | Buy groceries
23 |
24 | );
25 | ```
26 |
27 | Here we're searching for a `div` representing a todo item with the id 3. Because
28 | props are checked with `to satisfy`, extra data in this object is ignored.
29 |
30 | You can use `to have rendered` or `to contain` with all the options as usual following a `queried for`.
31 |
32 | It is also possible to extract the found component, by using the value of the returned promise from `expect`.
33 |
34 |
35 | ```js#async:true
36 | return expect(component, 'queried for', )
37 | .then(todoItem => {
38 | expect(todoItem.props.label, 'to equal', 'Buy groceries');
39 | });
40 | ```
41 |
42 | ## queryTarget
43 |
44 | If you want to find a target nested inside a parent element, use `queryTarget` in the query.
45 | e.g. This `queried for` clause returns the `span` inside the `TodoItem`
46 |
47 | ```js
48 | expect(
49 | component,
50 | 'queried for',
51 |
52 |
53 |
54 |
55 | ,
56 | 'to have rendered',
57 | Buy groceries
58 | );
59 | ```
60 |
--------------------------------------------------------------------------------
/documentation/assertions/RenderedReactElement/to-contain.md:
--------------------------------------------------------------------------------
1 | It's possible to check for a part of the subtree, without
2 | testing the entire returned tree. This allows you to test specific elements, without
3 | writing brittle tests that break when the structure changes.
4 |
5 | Assuming the following component output
6 | ```js
7 | class MyComponent extends React.Component {
8 | render () {
9 | return (
10 |
11 | one
12 | two
13 | three
14 |
15 | );
16 | }
17 | };
18 |
19 | var component = TestUtils.renderIntoDocument(
20 |
21 | );
22 | ```
23 |
24 | ```js
25 | // This will pass, as `two` can be found in the component's output
26 | expect(component, 'to contain', two);
27 | ```
28 |
29 | Notice that the extra `className="middle"` in the `two` is ignored,
30 | in a similar way to the `to have rendered` assertion.
31 |
32 | You can override this behaviour by using `'to contain exactly'`, and `'to contain with all children'`
33 |
34 |
35 | ```js
36 | // This will fail, as `two` cannot be found in the renderers output, due to
37 | // the missing `className="middle"` prop
38 | expect(component, 'to contain exactly', two);
39 | ```
40 |
41 | ```output
42 | expected
43 |
44 |
45 | one
46 | two
47 | three
48 |
49 |
50 | to contain exactly two
51 |
52 | the best match was
53 |
55 | two
56 |
57 | ```
58 |
59 | The same thing applies to children for `'to contain'` as for `'to have rendered'`.
60 |
61 |
--------------------------------------------------------------------------------
/documentation/assertions/RenderedReactElement/to-have-rendered.md:
--------------------------------------------------------------------------------
1 | Given the following test component:
2 |
3 | ```js
4 | class MyComponent extends React.Component {
5 | render () {
6 | return (
7 |
8 | one
9 | two
10 | three
11 |
12 | );
13 | }
14 | }
15 | ```
16 |
17 | Let's render the component with the virtual DOM renderer:
18 |
19 | ```js
20 | const component = TestUtils.renderIntoDocument();
21 | ```
22 |
23 | ```js
24 | // Extra props and children from the render are ignored
25 | expect(component, 'to have rendered', );
26 | ```
27 |
28 | ```js
29 | // The span "two" is missing here, but it is ignored.
30 | expect(component, 'to have rendered',
31 |
32 | one
33 | three
34 |
35 | );
36 | ```
37 |
38 | ```js
39 | // The following assertion will fail, as 'four' does not exist
40 | expect(component, 'to have rendered',
41 |
59 | one
60 |
61 | two // -two
62 | // +four
63 |
64 | three
65 |
66 |
67 | ```
68 |
69 | If you want to check for an exact render, use `'to have exactly rendered'`.
70 |
71 | Alternatively, if you don't care about extra props, but want to check that there are no extra child nodes, use `'to have rendered with all children'`
72 | Note that `exactly` implies `with all children`, so you using both options is not necessary.
73 |
74 | Normally wrappers (elements that simply wrap other components) are ignored. This can be useful if you have higher order
75 | components wrapping your components, you can simply ignore them in your tests (they will be shown greyed out
76 | if there is a "real" error). If you want to test that there are no extra wrappers, simply add
77 | `with all wrappers` to the assertion.
78 |
79 |
80 | ```js
81 | // The span "two" is missing here, as is `className="parent"`
82 | // The missing span will cause an assertion error, but the extra prop will be ignored
83 | // due to `to have rendered with all children` being used
84 |
85 | expect(component, 'to have rendered with all children',
86 |
104 | one
105 | two // should be removed
106 | three
107 |
108 |
109 | ```
110 |
111 | ```js
112 | // The span "two" is missing here, as is `className="parent"`
113 | // This will cause an assertion error,
114 | // due to `to have exactly rendered` being used
115 |
116 | expect(component, 'to have exactly rendered',
117 |
118 |
138 | one
139 | two // should be removed
140 | three
141 |
142 |
143 | ```
144 |
145 |
--------------------------------------------------------------------------------
/documentation/assertions/RenderedReactElement/to-match-snapshot.md:
--------------------------------------------------------------------------------
1 | Under [jest](https://facebook.github.io/jest/), you can use snapshots. Snapshot tests save a snapshot of the component as it is currently rendered to a `.snapshot` file under a directory `__snapshots__`. Note that the snapshots for `unexpected-react` are saved to a different filename than those jest uses natively. This is because the format differs slightly.
2 |
3 | Remember that to include snapshot support for the shallow and DOM renderers, you need to require unexpected-react as `require('unexpected-react/jest')`
4 |
5 | With `unexpected-react`, you can snapshot DOM rendered tests in exactly the same way.
6 |
7 | ```js
8 | class MyComponent extends React.Component {
9 | render () {
10 | return (
11 |
12 | one
13 | two
14 | three
15 |
16 | );
17 | }
18 | }
19 | ```
20 |
21 | Let's render the component with the virtual DOM renderer:
22 |
23 | ```js
24 | var component = TestUtils.renderIntoDocument();
25 | ```
26 |
27 | Then we can validate it matches the snapshot. If no snapshot exists, it will be automatically created the first time it is run.
28 |
29 | ```js#evaluate:false
30 | expect(component, 'to match snapshot');
31 | ```
32 |
33 | If in the future the component output changes, the error will be highlighted (using the same error highlighting used in the rest of unexpected-react).
34 |
35 | Once you have checked that the changes are correct, you can run `jest -u` to update the snapshot, or if running in watch mode, press `u`.
36 |
37 | ### Events
38 | Triggered events still works, and can be combined with matching snaphots.
39 |
40 | e.g.
41 |
42 | ```js#evaluate:false
43 | var component = TestUtils.renderIntoDocument();
44 |
45 | expect(component,
46 | 'with event click',
47 | 'to match snapshot'
48 | );
49 | ```
50 |
51 | ### Matching
52 |
53 | The snapshot matches everything, so extra classes and attributes will causes a difference to be highlighted. If you want your snapshots to work more like `to have rendered`, so new attributes, classes and child elements can be added without triggering a change, see the assertion `to satisfy snapshot`.
54 |
55 |
--------------------------------------------------------------------------------
/documentation/assertions/RenderedReactElement/to-satisfy-snapshot.md:
--------------------------------------------------------------------------------
1 | Under [jest](https://facebook.github.io/jest/), you can use snapshots. Snapshot tests save a snapshot of the component as it is currently rendered to a `.snapshot` file under a directory `__snapshots__`. Note that the snapshots for `unexpected-react` are saved to a different filename than those jest uses natively. This is because the format differs slightly.
2 |
3 | Remember that to include snapshot support for the shallow and DOM renderers, you need to require unexpected-react as `require('unexpected-react/jest')`
4 |
5 | With `unexpected-react`, you can snapshot DOM rendered tests in exactly the same way.
6 |
7 | ```js
8 | class MyComponent extends React.Component {
9 | render () {
10 | return (
11 |
12 | one
13 | two
14 | three
15 |
16 | );
17 | }
18 | }
19 | ```
20 |
21 | Let's render the component with the virtual DOM renderer:
22 |
23 | ```js
24 | var component = TestUtils.renderIntoDocument();
25 | ```
26 |
27 | Then we can validate it matches the snapshot. If no snapshot exists, it will be automatically created the first time it is run.
28 |
29 | ```js#evaluate:false
30 | expect(component, 'to satisfy snapshot');
31 | ```
32 |
33 | If in the future the component output changes, the error will be highlighted (using the same error highlighting used in the rest of unexpected-react).
34 |
35 | Once you have checked that the changes are correct, you can run `jest -u` to update the snapshot, or if running in watch mode, press `u`.
36 |
37 | ### Events
38 | Triggered events still works, and can be combined with matching snaphots.
39 |
40 | e.g.
41 |
42 | ```js#evaluate:false
43 | var component = TestUtils.renderIntoDocument();
44 |
45 | expect(component,
46 | 'with event click',
47 | 'to satisfy snapshot'
48 | );
49 | ```
50 |
51 | ### Matching
52 |
53 | The snapshot matches in the same way as `to have rendered`, so new classes, attributes and child nodes are not treated as a difference. This can be advantageous when you want to add new features to a component, but expect the existing component to keep the same basic template.
54 |
55 | If you'd prefer to match the template exactly (order of classes is still ignored), see the assertion `to match snapshot`.
56 |
--------------------------------------------------------------------------------
/documentation/assertions/RenderedReactElement/with-event.md:
--------------------------------------------------------------------------------
1 | ## `with event` .... [`on`]
2 |
3 | `with event` can trigger events in both the shallow and full renderer. For the normal full renderer,
4 | `TestUtils.Simulate` is used to simulate the event. For the shallow renderer, it is expected that
5 | there is a prop with the name `on[EventName]`, where the first letter of the event is capitalised.
6 |
7 | e.g. with a button that counts it's own clicks
8 |
9 | ```js
10 | var component = TestUtils.renderIntoDocument();
11 |
12 | expect(component, 'with event', 'click', 'to have rendered', );
13 | ```
14 |
15 | Given the following todo list:
16 |
17 | ```js
18 | var component = TestUtils.renderIntoDocument(
19 |
20 |
21 |
22 |
23 |
24 | );
25 | ```
26 |
27 | If you want to trigger an event on a specific component, (i.e. not the top level component), use `on`
28 | after the event.
29 |
30 | ```js
31 | expect(
32 | component,
33 | 'with event click',
34 | 'on', ,
35 | 'to contain',
36 |
37 | Buy groceries
38 |
39 | );
40 | ```
41 |
42 | To pass arguments to the event, simply include the event object after the event name
43 |
44 | ```js
45 | expect(
46 | component,
47 | 'with event mouseDown', { mouseX: 150, mouseY: 50 },
48 | 'on', ,
49 | 'to contain',
50 |
51 | Buy groceries
52 |
53 | );
54 | ```
55 |
56 | This will call the function passed in the `onMouseDown` prop of the ``.
57 |
58 | ## Multiple events
59 |
60 | To call multiple events, simple list them one after the other:
61 |
62 |
63 | ```js
64 | expect(component,
65 | 'with event click', { mouseX: 150, mouseY: 50 },
66 | 'on', ,
67 | 'with event click', { mouseX: 50, mouseY: 50 },
68 | 'on', ,
69 | 'to have rendered',
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 | );
81 | ```
82 |
83 | You can optionally add `and` before the second and further events, to make it easier to read:
84 |
85 | ```js
86 | expect(component,
87 | 'with event mouseDown', { mouseX: 150, mouseY: 50 },
88 | 'on', ,
89 | 'and with event mouseDown', { mouseX: 50, mouseY: 50 },
90 | 'on', ,
91 | 'to have rendered',
92 |
93 |
94 |
95 |
96 |
97 |
98 |
99 |
100 |
101 |
102 | );
103 | ```
104 |
105 | You can extract the renderer after an event by using the result of the promise returned from `expect`
106 |
107 | ```js#async:true
108 | return expect(
109 | component,
110 | 'with event mouseDown', { mouseX: 150, mouseY: 50 },
111 | 'on',
112 | ).then(renderer => {
113 | expect(
114 | renderer,
115 | 'to contain',
116 |
117 |
118 |
119 | );
120 | });
121 | ```
122 |
123 | ## eventTarget
124 |
125 | You can add an `eventTarget` prop to the expected to trigger the event on a child component.
126 | e.g. This will trigger the click in the `