Update testing documentation

grengojbo · Jan 26, 2016 · f43c0fb · f43c0fb
1 parent 0d7351f
commit f43c0fb
Show file tree

Hide file tree

Showing 3 changed files with 27 additions and 14 deletions.
diff --git 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
@@ -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
@@ -6,20 +6,16 @@ This boilerplate uses the [Mocha](https://github.com/mochajs/mocha) test framewo
 
 <!-- TOC depthFrom:2 depthTo:4 withLinks:1 updateOnSave:1 orderedList:0 -->
 
-- [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)
 
 <!-- /TOC -->
 
-## 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!