Merge branch 'master' of github.com:rht-labs/enablement-docs

donal

2018-04-27 74dadf30e13b279f21806287358bd001d57ab1e5

Merge branch 'master' of github.com:rht-labs/enablement-docs

 exercises/3-revenge-of-the-automated-testing/README.md

@@ -48,7 +48,7 @@
As a learner you will be able to

* Understand the why behind TDD
* Implement a feature using TDD for frontend and backend
* Implement a feature using TDD for front end and backend
* Write end to end tests for the feature and run them in CI

## Tools and Frameworks
@@ -89,10 +89,10 @@
> This is a fairly structured guide with references to exact filenames and sections of text to be added.

### Part 1 - Tests in our Pipeline
> _In this part we will get familiar with the layout of our tests. We will also improve the pipeline created already by adding some unit tests for the frontend & backend along with some end to end tests (e2e) to validate the full solution_
> _In this part we will get familiar with the layout of our tests. We will also improve the pipeline created already by adding some unit tests for the front end & backend along with some end to end tests (e2e) to validate the full solution_

#### 1a - FE Unit tests
> In this exercise we will execute our test for the frontend locally. Once verified we will add them to Jenkins.
> In this exercise we will execute our test for the front end locally. Once verified we will add them to Jenkins.

2. Before linking our automated testing to the pipeline we'll first ensure the tests run locally. Change to the `todolist-fe` directory and run `test`.
```bash
@@ -104,7 +104,7 @@
</p>
![screenshot-scripts](../images/exercise3/screenshot-scripts.png)

2. This command will run all `*spec.js` files. Our test files are stored in the following places. There are 12 Frontend test files stored in these directories: `todolist-fe/tests/unit/vue-components/*` & `todolist-fe/tests/unit/javascript/*`
2. This command will run all `*spec.js` files. Our test files are stored in the following places. There are 12 front end test files stored in these directories: `todolist-fe/tests/unit/vue-components/*` & `todolist-fe/tests/unit/javascript/*`

2. You should see an output similar to the following. The above command has run a test suite for every `*.spec.js` file. The table generated in the terminal shows the code coverage. We're going to be focusing on the unit tests for now.
![test-run-locally](../images/exercise3/test-run-locally.png)
@@ -299,7 +299,7 @@
  - `res.body.should.be.instanceof(Array);` is the actual test call
  - `done();` tells the test runner that `mocha` has finished execution. This is needed as the http calls are asynchronous.

3.  With this knowledge; let's implement our test for the `important` flag. We expect the fronted to introduce a new property on each `todo` that gets passed to the backend called `important`. The API will need to handle this new property and pass it into the mongodb. Let's begin implementing this functionality by writing our test case. Navigate to the `PUT /api/todos` section of the `server/api/todo/todo.spec.js` test file (which should be at the bottom) 
3.  With this knowledge; let's implement our test for the `important` flag. We expect the front end to introduce a new property on each `todo` that gets passed to the backend called `important`. The API will need to handle this new property and pass it into the mongodb. Let's begin implementing this functionality by writing our test case. Navigate to the `PUT /api/todos` section of the `server/api/todo/todo.spec.js` test file (which should be at the bottom) 
![todo-api-tests](../images/exercise3/todo-api-tests.png)

3. Before writing our test; let's first make sure all the existing tests are passing.
@@ -377,8 +377,8 @@
$ npm run start
```

#### Part 2b - Create todolist-fe tests
> Using [Jest](https://facebook.github.io/jest/) as our test runner and the `vue-test-utils` library for managing our vue components; we will now write some tests for frontend functionality to persist our important-flag. The changes required to the front end are quite large but we will use TDD to create our test first, then implement the functionality. 
#### 2b - Create todolist-fe tests
> Using [Jest](https://facebook.github.io/jest/) as our test runner and the `vue-test-utils` library for managing our vue components; we will now write some tests for front end functionality to persist our important-flag. The changes required to the front end are quite large but we will use TDD to create our test first, then implement the functionality. 

Our TodoList App uses `vuex` to manage the state of the apps' todos and `axios` HTTP library to connect to the backend. `Vuex` is an opinionated framework for managing application state and has some key design features you will need to know to continue with the exercise. 


 exercises/6-return-of-the-app-monitoring/README.md

@@ -72,7 +72,7 @@

2. Open the `todolist-fe` app in your favourite editor. In this exercise, we will fail a test and capture the message in the log and visualise it on a dashboard.

2. Open the one of the tests you wrote in previous labs; for example `tests/unit/vue-components/TodoItem.spec.js`. Negate the test at the very bottom of the file to by adding a `.not` to the `expect()` statement as shown below.
2. Open one of the tests you wrote in previous labs; for example `tests/unit/vue-components/TodoItem.spec.js`. Negate the test at the very bottom of the file by adding a `.not` to the `expect()` statement as shown below.
```javascript
  it("call makImportant when clicked", () => {
    const wrapper = mount(TodoItem, {
@@ -87,15 +87,15 @@
});
```

2. Run your tests locally and you should see one failing test as shown below. Jenkins will have the same out put so we can capture this as code!
2. Run your tests locally and you should see one failing test as shown below. Jenkins will have the same output so we can capture this as code!
![fail-local](../images/exercise6/fail-local.png)

2. The `Test Suites: 1 failed, 11 passed, 12 total` string can be coded into a regex. On Jenkin homepage; hit the `Failure Cause Management` nav on the left hand menu. On the page that loads; hit `Create new`.
2. The `Test Suites: 1 failed, 11 passed, 12 total` string can be coded into a regex. On Jenkins homepage; hit the `Failure Cause Management` nav on the left hand menu. On the page that loads; hit `Create new`.

2. Call the new Failure Cause `jest-tests`. Set the Description to be `${1,1} failed out of ${1,2}`. The `${1,1}` refers to the first capture group in a regex. Click `Add indication > Build log`. Set the Pattern to match for the test output we've seen in our test execution on the terminal using this regex `.*Tests:.*(\d+) failed.*(\d+) total.*`. 
![fail-cause](../images/exercise6/fail-cause.png)

2. Our dashboards are set to show the `Description` field from the `Build Fail Analyser`. Run a build by checking in our failed tests and check the result on the Build Monitor created in previous step
2. Our dashboards are set to show the `Description` field from the `Build Fail Analyser`. Run a build by checking in our failed tests and check the result on the Build Monitor created in the previous step
```bash
$ git add .
$ git commit -m "TEST - failing build"