From f43c0fbb1ee96b24014e93efa80ebdee88160211 Mon Sep 17 00:00:00 2001 From: Max Date: Tue, 26 Jan 2016 20:39:15 +0100 Subject: [PATCH] Update testing documentation --- docs/testing/README.md | 16 ++++++++++++++++ docs/testing/remote-testing.md | 6 ++++-- docs/testing/unit-testing.md | 19 +++++++------------ 3 files changed, 27 insertions(+), 14 deletions(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index f00b526a98..5bfbce58b3 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -1 +1,17 @@ # Testing + +Testing your application is a vital part of serious development. There are a few things you should test. If you've never done this before start with [unit testing](unit-testing.md). Move on to [component testing](component-testing.md) when you feel like you understand that! + +We also support [remote testing](remote-testing.md) your local application, which is quite awesome, so definitely check that out! + +## Usage with this boilerplate + +To test your application started with this boilerplate do the following: + +1. Sprinkle `.test.js` files directly next to the parts of your application you want to test. (Or in `test/` subdirectories, it doesn't really matter as long as they are directly next to the parts and end in `.test.js`) + +2. Write your unit and component tests in those files. + +3. Run `$ npm run test` in your terminal and see all the tests pass! (hopefully) + +There are a few more commands related to testing, checkout the [commands documentation](../general/commands.md#testing) for the full list! diff --git a/docs/testing/remote-testing.md b/docs/testing/remote-testing.md index dd9deed52b..83f5ad8322 100644 --- a/docs/testing/remote-testing.md +++ b/docs/testing/remote-testing.md @@ -1,7 +1,9 @@ -# Testing from different locations +# Remote testing ```Shell $ npm run serve ``` -This command will start a server and tunnel it through with `ngrok`. This'll give you a URL that looks a bit like this: `xxxxx.ngrok.com` This URL will show the version of your application that's in the `build` folder, and is accessible from the entire world! This is great for testing on different devices from different locations! +This command will start a server and tunnel it with `ngrok`. You'll get a URL that looks a bit like this: `http://abcdef.ngrok.com` + +This URL will show the version of your application that's in the `build` folder, and it's accessible from the entire world! This is great for testing on different devices and from different locations! diff --git a/docs/testing/unit-testing.md b/docs/testing/unit-testing.md index 42b3c99289..7e6d39ec2e 100644 --- a/docs/testing/unit-testing.md +++ b/docs/testing/unit-testing.md @@ -6,20 +6,16 @@ This boilerplate uses the [Mocha](https://github.com/mochajs/mocha) test framewo -- [General](#general) +- [Basics](#basics) - [Mocha](#mocha) - [expect](#expect) -- [Real World Usage](#real-world-usage) +- [Testing Redux Applications](#testing-redux-applications) - [Reducers](#reducers) - [rewire](#rewire) - [Actions](#actions) - - [Synchronous actions](#synchronous-actions) - - [Asynchronous actions](#asynchronous-actions) -## General - We use this glob pattern to find unit tests `app/**/*.test.js` - this tells mocha to run all files that end with `.test.js` anywhere within the `app` folder. Use this to your advantage, and put unit tests next to the files you want to test so relevant files stay together! Imagine a navigation bar, this is what its folder might look like: @@ -36,6 +32,8 @@ NavBar # Wrapping folder │ └── NavBar.reducer.test.js # Reducer tests ``` +## Basics + For the sake of this guide, lets pretend we're testing this function. It's situated in the `add.js` file: ```JS @@ -163,7 +161,7 @@ add() This tells us that something is broken in the add function before any users get the code! Congratulations, you just saved time and money! -## Real World Usage +## Testing Redux Applications This boilerplate uses Redux, partially because it turns our data flow into testable (pure) functions. Lets go back to our `NavBar` component from above, and see what testing the actions and the reducer of it would look like. @@ -289,8 +287,7 @@ import rewire from 'rewire'; import NavBarReducer from '../NavBar.reducer'; import { TOGGLE_NAV } from '../NavBar.constants'; -const rewiredNavBarReducer = rewire('../NavBar.reducer'); -const initialState = rewiredNavBarReducer.__get__('initialState'); +const initialState = NavBarReducer.__get__('initialState'); ``` > Note: You might be wondering why we still `import` the `NavBarReducer` above. The `NavBarReducer` imported with `rewire` isn't the actual reducer, it's a `rewire`d version. @@ -309,9 +306,7 @@ Lets see how we can test actions next. ### Actions -We have one synchronous action `toggleNav` that changes the `NavBar` open state. - -#### Synchronous actions +We have one action `toggleNav` that changes the `NavBar` open state. A Redux action is a pure function, so testing it isn't more difficult than testing our `add` function from the first part of this guide!