1262865 - Add docs for testing React/Redux

Status: NEW

(DevTools :: Shared Components, defect)

Comment 1

[Lin Clark [:linclark]]

Attachment: Bug1262865-testing-docs.patch

Comment 2

[James Long (:jlongster)]

Comment on attachment 8739076 [details] [diff] [review]
Bug1262865-testing-docs.patch

Review of attachment 8739076 [details] [diff] [review]:
-----------------------------------------------------------------

I feel a better way to structure this is based on test type: have the section headers be unit, integration, and end-to-end tests. Within those provide guidelines on various things that you can test that way. I thought integration tests were mochitests, and I don't really understand the difference between them and end-to-end tests?

I guess we're doing things a little different in debugger.html: unit test reducers and components, and use actions as integration tests. Some of these integration tests only test one action, some of them test interaction of multiple of them. These is testing how the UI interacts because it's testing how state changes over time. I was thinking of doing them as mochitests, but I like the idea of trying to mock the protocol so they could run without a browser. And then have some mochitests for what you call true integration tests.

Anyway, I guess it's a question of how prescriptive we want to be. I think with all the various projects going on with multiple things, it's hard to be too prescriptive. I don't think we will all write tests totally the same, but we should find some consistency. For now, instead of saying which types of tests to use for which part of the system, are you ok with more of a guidelines approach? That would be grouping by test type and discussing what *could* be tested that way.

::: devtools/docs/react-guidelines.md
@@ +77,5 @@
> +- End-to-end tests fire up the full application and test everything together
> +
> +As much as possible, we want to write unit and integration tests. End-to-end tests should be used sparingly.
> +
> +### Action creator tests (unit)

I actually expected action creators to be integration, or even end-to-end. They do async work and are the things that drive the whole app. We don't use anything like sages or effects, so they rely on a connection object existing and the ability to make protocol requests.

We're still figuring this out in debugger.html. I suppose it would be cool to mock out the connection object and be able to unit test actions. But I'm not sure we'll be able eto do that for all of them.

@@ +94,5 @@
> +- In the test, use the action creators (which have already been tested) to create actions and dispatch on stores.
> +- If components pull values directly from the state object during connect, then test the state object shape.
> +- On the other hand, if components use selector functions (either on the reducers or using reselect), then test that calling those selectors gets the expected state.
> +
> +In addition to store integration tests, you may want to unit test reducers and selectors.

Reducers are a great thing to test individually. They are super easy: write a bunch of unit tests that pumps actions through and make sure the state is correct.

Comment 3

[Lin Clark [:linclark]]

This breakdown reflects my own personal testing background, e.g. what I learned in school and at other companies. It is different from some of the current vocabulary used here... though the existing testing story generally isn't 100% coherent, either. If people don't like this breakdown, that's ok. We don't need to include it.

1. In my experience unit tests focus on an individual module or function. Many of the tests that are currently in the "unit" folders in tree would not fall under that category in contexts I've worked before.
2. Integration tests make sure that different units of code work together. They test the integration between 2 or more units.
3. End-to-end tests ensure that *all* pieces are working together, usually by firing up a browser and clicking around. They are a particular subset of integration tests.

Again, if those distinctions don't make sense to others, we don't have to include them.

> I actually expected action creators to be integration, or even end-to-end.
> They do async work and are the things that drive the whole app. We don't use
> anything like sages or effects, so they rely on a connection object existing
> and the ability to make protocol requests.

The Redux docs recommend unit tests for action creators: http://redux.js.org/docs/recipes/WritingTests.html

Once the unit test ensures that the action creator creates the expected action, then the action creator can be used in integration tests. This helps isolate problems a little bit. If the unit test for the action creator is creating the expected action, then you know the problem isn't there.

In the console rewrite, our action creators don’t currently depend on a connection object existing. I’m not sure if that’s because of a fundamental difference between the tools, or if we haven’t hit that point yet, or if it’s just a different approach.

> Reducers are a great thing to test individually. They are super easy: write
> a bunch of unit tests that pumps actions through and make sure the state is
> correct.

Yeah, originally I had only written reducer tests, but then switched it to full store tests to match memory tool, RDM, etc. If the reducers are simple, then the store tests should cover the same ground. In the case of more complex logic in reducers, individual unit tests would provide an easier way to test.