view | history | commit | commitdiff
Rob Harris
2018-04-17 7c82c1bb18986f51fb3e8668a2cab6212ae03e9b
commit | author | age
92e460 1 # Revenge Of The Automated Testing
43f2f2 2
5285f8 3 > The purpose of this lab is to develop and validate a new feature using TDD; and to promote the assured feature through the pipeline.
f6d2bd 4
62a054 5 ![comic-header](../images/exercise3/comic-header.png)
RH 6
7 [Image Source](https://cdn-images-1.medium.com/max/1600/1*wF_fSCH-gLYfMbkwb3gR2w.png)
8
f6d2bd 9 ---
43f2f2 10
D 11 ## Learning Outcomes
f6d2bd 12
43f2f2 13 As a learner you will be able to
f6d2bd 14
5285f8 15 * Understand the why behind TDD
D 16 * Implement a feature using TDD for frontend and backend
17 * Write end to end tests for the feature and run them in CI
43f2f2 18
D 19 ## Tools and Frameworks
f6d2bd 20
43f2f2 21 > Name of tool - short description and link to docs or website
D 22
5285f8 23 1.  [Jest](https://facebook.github.io/jest/) - Zero configuration testing platform
D 24 Jest is used by Facebook to test all JavaScript code including React applications. One of Jest's philosophies is to provide an integrated "zero-configuration" experience. We observed that when engineers are provided with ready-to-use tools, they end up writing more tests, which in turn results in more stable and healthy code bases.
25 1.  [Vue Test Utils](https://vue-test-utils.vuejs.org/en/) - Vue Test Utils is the official unit testing utility library for Vue.js.
26 1.  [Nightwatch.js](http://nightwatchjs.org/) - Nightwatch.js is an easy to use Node.js based End-to-End (E2E) testing solution for browser based apps and websites. It uses the powerful W3C WebDriver API to perform commands and assertions on DOM elements.
27 1.  [Mocha](https://mochajs.org/) - Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Hosted on GitHub.
28 1.  [Sinon](http://sinonjs.org/) - Standalone test spies, stubs and mocks for JavaScript. 
29 Works with any unit testing framework.
43f2f2 30
D 31 ## Big Picture
f6d2bd 32
43f2f2 33 This exercise begins cluster containing blah blah
D 34
f6d2bd 35 ---
43f2f2 36
D 37 ## 10,000 Ft View
38
5285f8 39 > The goal of this exercise is to add a new component to the application using TDD to create and validate it's behaviour. The User story we have been given is as follows:
43f2f2 40
5285f8 41 *As a doer I want to mark todos as important so that I can keep track of and complete high prirority todos first*
f6d2bd 42
5285f8 43 _Acceptance Criteria_
D 44 - [ ] should be doable with a single click
45 - [ ] should add a red flag against the todo when marked important
46 - [ ] should remove the red colour flag on the flag when important removed
47 - [ ] should not affect existing todos
48
49 _On page load:_
50 - [ ] should display existing todos that are not marked important
51 - [ ] should display existing todos that are marked important with an red flag
43f2f2 52
D 53 ## Step by Step Instructions
91cc51 54 > This is a fairly structured guide with references to exact filenames and sections of text to be added.
43f2f2 55
03b14c 56 ### Part 0 - Introduction to TDD.
A 57 > _We'll show you what TDD is, and introduce our existing tests within our code._
58
59 #### Part 0a - What is TDD?
60 > _Here is a brief introduction of TDD and why we use it._
61
7e6765 62 **Test Driven Development (TDD)** is a software development process that relies on the repetition of a very short development cycle. Requirements are turned into test cases, where the software is developed to pass the tests. In other words, it creates a safety net that serves to keep the developer's problems/bugs at bay while enabling the developer to refactor efficiently. This is opposed to software development that allows software to be added that is not proven to meet requirements.
03b14c 63
73774f 64 The TDD cycle can be illustrated with the following diagram;
7e6765 65 ![TDD-diagram](../images/exercise3/TDD-lifecycle.jpg)
03b14c 66
73774f 67 ## The TDD Cycle 
RH 68
69 1. `Write a test` -
70 In TDD a new feature begins by writing a test. Write a test that can clearly defines a function or one that provides an improvement to a function. It is important the developer clearly understands the features' specification and requirements or the function could be wrong from the get-go. 
71
72 2. `Test Fails` -
73 When a test is first implemented it is expected to fail. This failure validates the test is working correctly as the feature is yet to be implemented. 
74
75 3. `Write code to make test pass` -
76 This step involves implementing the feature to pass the failed test. Code written at this stage may pass the test in an inelegant way, however this is acceptable as TDD is a recursive cycle which includes code refactoring.
77
78 4. `Code Passes tests` -
79 If all tests pass, the developer can be confident that the new code meets the test requirements.
80
81 5. `Refactor` -
82 The refactoring step will allow the developer to clean up their code without changing its behaviour. This ensures it still passes all the tests. The process of refactoring can include; removal of duplication, renaming of Object, class, module, variable and method names to clearly represent their current purpose and use, decoupling of functionality and increasing code cohesion.
83
84 6. `Repeat` -
85 Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging.
86
03b14c 87 #### Part 0b - Introduction to our tests.
A 88 > _In this part we will get familiar with the layout of our tests_
89
f56999 90 2. We'll go into detail on how to write tests further on. To run your test suites run the following in the root of your `todolist-fe` or `todolist-api` repositories.
A 91 ```bash
92 $ npm run test
93 ```
94
95 2. This command will run all `*spec.js` files. Our test files are stored in the following places:
03b14c 96
b6ebf8 97   - There are 2 Api test files: `todolist-api/server/api/todo/todo.spec.js` & `todolist-api/server/mocks/mock-routes.spec.js`
A 98
99   - There are 12 Frontend test files stored in these directories: `todolist-fe/tests/unit/vue-components/*` & `todolist-fe/tests/unit/javascript/*`
f56999 100
536726 101 2. Explanation of Mocha and js test syntax through Bananalogy:
f56999 102 ![todoitem-fail-test](../images/exercise3/bdd-bananas.png)
A 103
92e460 104   * TODO - expand upon this.
A 105   * `describe` is used to group tests together. The string `"a bunch of ripe bananas"` is for human reading and allows you to identify tests.
106   * `it` is a statement that contains a test. It should contain an assertion such as `expect` or `should`. It follows the syntax of `describe` where the string passed in identifies the statement.
43f2f2 107
536726 108 2. Visit [mochajs.org](https://mochajs.org/) for more in-depth documentation.
034b0f 109
f6d2bd 110 ### Part 1 - Tests in our Pipeline
bc2216 111 > _In this exercise we will 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_
43f2f2 112
bc2216 113 #### Part 1a - Unit tests
bc975e 114 > In this exercise we will execute our test for the frontend and backend locally. Once verified we will add them to Jenkins.
bc2216 115
bc975e 116 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`.
91cc51 117 ```bash
A 118 $ cd todolist-fe
119 $ npm run test
120 ```
121 <p class="tip" > 
60bca4 122 `test` is an alias used that runs `vue-cli-service test` from the scripts object in `package.json`
91cc51 123 </p>
A 124 ![new-gitlab-proj](../images/exercise3/screenshot-scripts.png)
bc2216 125
91cc51 126 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.
A 127 ![new-gitlab-proj](../images/exercise3/test-run-locally.png)
128
129 2. Repeat the same process for `todolist-api` and verify that all the tests run.
130 ```bash
131 $ cd todolist-api
132 $ npm run test
133 ```
6e5072 134
91cc51 135 2. Navigate to your instance of jenkins at `https://jenkins-<YOUR_NAME>-ci-cd.apps.s8.core.rht-labs.com/`. 
A 136 Click on `dev-todolist-fe-build` and then click the `configure` button on the left-hand side.
137 ![new-gitlab-proj](../images/exercise3/jenkins-configure-job.png)
138
139 2. Scroll to the `Build` part of the configuration page and add `scl enable rh-nodejs8 'npm run test'` below `scl enable rh-nodejs8 'npm install'`. Click `save` or `apply` at the bottom to save the changes.
140 ![new-gitlab-proj](../images/exercise3/jenkins-build-step.png)
141
60bca4 142 2. Scroll to the `Post-build Actions` section and click `Add post-build action`. Select `Publish xUnit test result report`.
A 143 ![new-gitlab-proj](../images/exercise3/xunit-action.png)
6e5072 144
A 145 2. Click the `Add` button under `Publish xUnit test result report` and select `JUnit`. In the pattern field enter `test-report.xml`. In the `Failed Tests Thresholds`  input box enter 0 under `Red Ball Total`. It should look a little something like this:
146 ![new-gitlab-proj](../images/exercise3/post-build-actions.png)
147
f56999 148 2. Click `save` or `apply` at the bottom to save the changes. Run the `dev-todolist-fe-build` job and verify that this passes and the `build` and `bake` jobs are both triggered.
6e5072 149
A 150 2. We're now going to deliberately fail a test to ensure that `bake` and `deploy` jobs aren't triggered if any tests fail. Go to `ListOfTodos.spec.js` in `/tests/unit/vue-components` and head to `line 38`. Add `not.` before `toHaveBeenCalled()`.
151 ![new-gitlab-proj](../images/exercise3/change-test-to-fail.png)
152
f56999 153 2. Push this to Gitlab and run the build job.
6e5072 154 ```bash
A 155 $ git add .
156 $ git commit -m "Deliberately failed test to test the pipeline stops me deploying broken code"
157 $ git push
158 ```
159
160 2. Rerun the `dev-todolist-fe-build` job. It should have failed and not run any other builds. 
161 ![new-gitlab-proj](../images/exercise3/jenkins-with-failing-build.png)
162
2717b2 163 2. Undo the changes you made to the `ListOfTodos.spec.js` file, commit your code and rerun the build. This should trigger a full `build --> bake --> deploy` of `todolist-fe`.
A 164
165 2. We're now going to do the same for the api. Head to the `configure` panel of the `dev-todolist-api-build` job. 
166
167 2. Add `scl enable rh-nodejs8 'npm run test:ci'` above `npm run build:ci`.
168 ![new-gitlab-proj](../images/exercise3/api-build-step.png)
169
4f979b 170 2. Scroll to the `Post-build Actions` section and click `Add post-build action`. Select `Publish xUnit test result report`.
2717b2 171
A 172 2. Click the `Add` button under `Publish xUnit test result report` and select `JUnit`. In the pattern field enter `reports/server/mocha/test-results.xml`. In the `Failed Tests Thresholds`  input box enter 0 under `Red Ball Total`. It should look a little something like this:
173 ![new-gitlab-proj](../images/exercise3/api-post-build.png)
174
175 2. We're now going to deliberately fail a test again to ensure that `bake` and `deploy` jobs aren't triggered if any tests fail. Go to `todo.spec.js` in `/server/api/todo` and head to `line 35`. Replace `false` with `true`. 
176 ![new-gitlab-proj](../images/exercise3/api-fail-build.png)
177
f56999 178 2. Push this to Gitlab and run the build job.
2717b2 179 ```bash
A 180 $ git add .
181 $ git commit -m "Deliberately failed test to test the pipeline stops me deploying broken code"
182 $ git push
183 ```
184
f56999 185 2. If successful this will fail the build and not run the `bake` or `deploy` jobs. 
A 186
187 <p class="tip">
188   NOTE - Don't forget to undo the changes that you made to your tests!
189 </p>
2717b2 190
bc2216 191 #### Part 1b - End to End tests (e2e)
4f979b 192 > TODO - this section is not complete
bc2216 193
f6d2bd 194 2.  Add new part to the dev pipeline (`dev-todolist-fe-e2e`)
bc2216 195
4f979b 196 2. Add e2e tests and reporting to Jenkins
bc2216 197
5285f8 198 ### Part 2 - TodoList new feature
bc2216 199 > _In this exercise we will introduce a new feature to create an important flag on the todos. In order to be able to build and test our feature we will use TDD_
D 200
5285f8 201 *As a doer I want to mark todos as important so that I can keep track of and complete high prirority todos first*
bc2216 202
5285f8 203 _Acceptance Criteria_
D 204 - [ ] should be doable with a single click
205 - [ ] should add a red flag against the todo when marked important
206 - [ ] should remove the red colour flag on the flag when important removed
207 - [ ] should not affect existing todos
bc2216 208
5285f8 209 _On page load:_
D 210 - [ ] should display existing todos that are not marked important
211 - [ ] should display existing todos that are marked important with an red flag
bc2216 212
f6d2bd 213 #### Part 1a - Create todolist-api tests
5285f8 214 > Using [Mocha](https://mochajs.org/) as our test runner; we will now write some tests for backend functionality to persist our important-flag. The changes required to the backend are minimal but we will use TDD to create our test first, then implement the functionality.
f6d2bd 215
D 216 3.  Create a new branch in your `todolist-api` app for our feature and push it to the remote
bc2216 217 ```bash
D 218 $ git checkout -b feature/important-flag
219 $ git push -u origin feature/important-flag
43f2f2 220 ```
D 221
f6d2bd 222 3.  Navigate to the `server/api/todo/todo.spec.js` file. This contains all of the existing todo list api tests. These are broken down into simple `describe("api definition", function(){})` blocks which is BDD speak for how the component being tested should behave. Inside of each `it("should do something ", function(){})` statements we use some snappy language to illustrate the expected behaviour of the test. For example a `GET` request of the api is described and tested for the return to be of type Array as follows.
D 223 ```javascript
224 describe("GET /api/todos", function() {
225     it("should respond with JSON array", function(done) {
226         request(app)
227         .get("/api/todos")
228         .expect(200)
229         .expect("Content-Type", /json/)
230         .end(function(err, res) {
231             if (err) return done(err);
232             // Test goes here
233             res.body.should.be.instanceof(Array);
234             done();
235         });
5285f8 236       });
f6d2bd 237 });
D 238 ```
239 where:
5285f8 240 _ `describe` is used to group tests together into a collection asserting some feature; for example the get all todos api.
D 241 _ `it` is an individual test statement and should contain an `expect` or a `should` statement asserting behaviour of the API under test.
242 _ `request` is a library for making http calls to the api.
243 _ `.expect(200)` asserts the HTTP Return Code
244 _ `res.body.should.be.instanceof(Array);` is the actual test call
245 _ `done();` tells the test runner that `mocha` has finished execution. This is needed as the http calls are asynchronous.
43f2f2 246
5285f8 247 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 test which should be at the bottom ![todo-api-tests](../images/exercise3/todo-api-tests.png).
f6d2bd 248
5285f8 249 3.  Before writing our test; let's first make sure all the existing tests are passing.
D 250 ```bash
f6d2bd 251 $ npm run test
D 252 ```
253
5285f8 254 3.  With all the tests passing; let's add our new one. For ease of completing this exercise a template of a new test has been written at the very end of the file. A PUT request responds in our API with the data that it just updated, so provided that MongoDB accepted the change, it will respond with an object that has the `important` property on it. To write our test; edit the `it("should ....", function(done) {` by completing the following:
f6d2bd 255     * Edit the `it("should ...")` to describe the imporant flag we're testing
D 256     * Edit the `.send()` to include `important: true` property
257     * Add a new test assertion to check that `res.body.important` is `true` below the `// YOUR TEST GO HERE` line.
258 ```javascript
5285f8 259 it("should mark todo as important and persist it", function(done) {
f6d2bd 260     request(app)
D 261       .put("/api/todos/" + todoId)
5285f8 262       .send({
D 263         title: "LOVE endpoint/server side testing!",
264         completed: true,
265         important: true
266       })
f6d2bd 267       .expect(200)
D 268       .expect("Content-Type", /json/)
269       .end(function(err, res) {
5285f8 270           if (err) return done(err);
D 271           res.body.should.have.property("_id");
272           res.body.title.should.equal("LOVE endpoint/server side testing!");
273           // YOUR TEST GO HERE
274           res.body.important.should.equal(true);
275           done();
f6d2bd 276       });
5285f8 277 });
f6d2bd 278 ```
D 279
5285f8 280 3.  Run your test. It should fail.
D 281 ```bash
f6d2bd 282 $ npm run test
D 283 ```
284 ![fail-mocha](../images/exercise3/fail-mocha.png)
285
5285f8 286 3.  With our test now failing; let's implement the feature. This is quite a simple change; all we need to do it update the `server/api/todo/todo.model.js` to allow an additional property on the schema called `important` of type Boolean.
f6d2bd 287 ```javascript
D 288 const TodoSchema = new Schema({
5285f8 289   title: String,
D 290   completed: Boolean,
291   important: Boolean
f6d2bd 292 });
D 293 ```
294
5285f8 295 3.  With your changes to the Database schema updated; re-run your tests.
D 296 ```bash
f6d2bd 297 $ npm run test
D 298 ```
299
5285f8 300 3.  Commit your code to the `feature/important-flag` branch and then merge onto the `develop` branch as follows
f6d2bd 301 <p class="tip">
D 302 NOTE - At this point in a residency we would peer review the code before pushing it to develop or master branch!
303 </p>
5285f8 304 ```bash
f6d2bd 305 $ git add .
D 306 $ git commit -m "ADD backend schema updates"
307 $ git checkout develop
308 $ git merge feature/important-flag
309 $ git push --all
310 ```
311
312 #### Part 1b - Create todolist-fe tests
5285f8 313 > 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 fronted 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. 
f6d2bd 314
5285f8 315 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. 
f6d2bd 316
5285f8 317 In `vuex` the application state is managed by a `store`. The `store` houses all the todos we have retrieved from the backend as well as the `getter` methods for our array of `todos`. In order to make changes to the store, we could call the store directly and update each todo item but as earlier said; vuex is an opinionated module with it's own way of updating the store. It is bad practice to call the store directly. 
D 318
319 There are two parts of the lifecycle to updating the store, the `actions` & `mutations`. When the user clicks a todo to mark it as complete; the `actions` are called. An action could involve a call to the backend or some pre-processing of the data. Once this is done, the change is committed to the store by calling the `mutation` function. A store should only ever be manipulated through a mutation function. Calling the mutation will then update the todo object in the apps local store for rendering in the view.
320
321 For example; when marking a todo as done in the UI, the following flow occurs
322     * The `TodoItem.vue` calls the `markTodoDone()` function which dispatches an event to the store.
323     * This calls the `updateTodo()` function in the `actions.js` file
324     * The action will update the backend db (calling our `todolist-api`) with our updated todo object.
325     * The action will commit the change to the store by calling the mutation method `MARK_TODO_COMPLETED`
326     * The `MARK_TODO_COMPLETED` will directly access the store object and update it with the new state value
327     * The `ListOfTodos.vue` component is watching the store for changes and when something gets updated it re-renders the `TodoItem.vue`.
328
329 3. Let's implement our feature by first creating a branch. Our new feature, important flag will behave in the same way as the `MARK_TODO_COMPLETED`. Create a new branch in your `todolist-fe` app for our feature and push it to the remote
f6d2bd 330 ```bash
D 331 $ git checkout -b feature/important-flag
332 $ git push -u origin feature/important-flag
333 ```
bc2216 334
5285f8 335 3. Let's get our tests running by executing a `--watch` on our tests. This will keep re-running our tests everytime there is a file change. All the tests should be passing when we begin
D 336 ```bash
337 $ npm run test -- --watch
338 ```
339
bc581a 340 3. There are three places we will add new tests to validate our function behaves as expected against the acceptance criteria from Feature Story supplied to us. We will need to write tests for our `TodoItem.vue` to handle having a red flag and that it is clickable. Our app is going to need to persist the changes in the backend so we'll want to make changes to our `actions.js` and `mutations.js` to keep the api and local copy of the store in sync. Let's start with our `TodoItem.vue` component. Open the `tests/unit/vue-components/TodoItem.spec.js` file. This has been templated with some example test to correspond with our A/Cs for speed of doing the lab. Find the describe block for our important flag tests. It is setup already with a `beforeEach()` hook for test setup.
5285f8 341 ![important-flag-before](../images/exercise3/important-flag-before.png)
D 342
343 3. Each of our test cases has it's skeleton in place already for example the `TodoItem.vue` component takes a property of `todos` when rendering. This setup is already done for each of our tests so all we have to do is fill in our assertions.
344 ![todoitem-skeleton-tests](../images/exercise3/todoitem-skeleton-tests.png)
345
346 3. Let's implement the first test `it("should render a button with important flag"`. This test will assert if the button is present on the page and it contains the `.important-flag` CSS class. To implement this; add the expect statement as follows.  
347 ```javascript
348   it("should render a button with important flag", () => {
349     const wrapper = mount(TodoItem, {
350       propsData: { todoItem: importantTodo }
351     });
352     // TODO - test goes here!
353     expect(wrapper.find(".important-flag").exists()).toBe(true);
354   });
355 ```
356
357 3. Save the file and we should see in our test watch the test case has started failing because we have not yet implemented the feature!
358 ![todoitem-fail-test](../images/exercise3/todoitem-fail-test.png)
359
360 3. With a basic assertion in place, let's continue on to the next few tests. We want the important flag to be red when an item in the todolist is marked accordingly. Conversely we want it to be not red when false. Let's create a check for `.red-flag` CSS property to be present when imporant is true and not when false.
361 ```javascript
362   it("should set the colour to red when true", () => {
363     const wrapper = mount(TodoItem, {
364       propsData: { todoItem: importantTodo }
365     });
366     // TODO - test goes here!
367     expect(wrapper.find(".red-flag").exists()).toBe(true);
368   });
369   it("should set the colour to not red when false", () => {
370     importantTodo.important = false;
371     const wrapper = mount(TodoItem, {
372       propsData: { todoItem: importantTodo }
373     });
374     // TODO - test goes here!
375     expect(wrapper.find(".red-flag").exists()).toBe(false);
376   });
377 ```
378
bc581a 379 3. Finally, we want to make the flag clickable and for it to call a function to update the state. The final test in the `TodoItem.spec.js` we want to create should simulate this behaviour. Implement the `it("call makImportant when clicked", () ` test by first simulating the click of our important-flag and asserting the function `markImportant()` to write is executed.
5285f8 380 ```javascript
D 381   it("call makImportant when clicked", () => {
382     const wrapper = mount(TodoItem, {
383       methods,
384       propsData: { todoItem: importantTodo }
385     });
386     // TODO - test goes here!
387     const input = wrapper.find(".important-flag");
388     input.trigger("click");
389     expect(methods.markImportant).toHaveBeenCalled();
390   });
391 ```
392
393 3. With our tests written for the feature's UI component, let's implement our code to pass the tests. Open up the `src/components/TodoItem.vue`. Each vue file is broken down into 3 sections
394     * The `<template></template>` contains the HTML of our component. This could include references to other Components also
395     * The `<script></script>` contains the JavaScript of our component and is essentially the logic for our component. It defines things like `properties`, `methods` and other `components`
396     * The `<style></style>` contains the encapsulated CSS of our component
397 Underneath the `</md-list-item>` tag, let's add a new md-button. Add a `.important-flag` class on the `md-button` and put the svg of the flag provided inside it.
398 ```html
399     </md-list-item>
400     <!-- TODO - SVG for use in Lab3 -->
401     <md-button class="important-flag">
402         <svg height="24" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" ><path d="M0 0h24v24H0z" fill="none"/><path d="M14.4 6L14 4H5v17h2v-7h5.6l.4 2h7V6z"/></svg>
403     </md-button>
404 ```
405
406 3. We should now see the first of our failing tests has started to pass. Running the app locally (using `npm run serve`) should show the flag appear in the UI. It is clickable but won't fire any events and the colour is not red as per our requirement. Let's continue to implement the colour change for the flag. On our `<svg/>` tag, add some logic to bind the css to the property of a `todo.important` by adding ` :class="{'red-flag': todoItem.important}"  `. This logic will apply the CSS class when `todo.important`  is true.
407 ```html
408 <md-button class="important-flag">
409     <svg :class="{'red-flag': todoItem.important}"  height="24" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" ><path d="M0 0h24v24H0z" fill="none"/><path d="M14.4 6L14 4H5v17h2v-7h5.6l.4 2h7V6z"/></svg>
410 </md-button>
411 ```
412
413 3. More tests should now be passing. Let's wire the click of the flag to an event in Javascript. In the methods section of the `<script></script>` tags in the Vue file, implement the `markImportant()`. We want to wire this to the action to updateTodo, just like we have in the `markCompleted()` call above it. We also need to pass and additional property to this method call `imporant`
414 ```javascript
415     markImportant() {
416       // TODO - FILL THIS OUT IN THE LAB EXERCISE
417       this.$store.dispatch("updateTodo", {id: this.todoItem._id, important: true});
418       console.info("INFO - Mark todo as important ", this.todoItem.important);
419     },
420 ```
421
422 3. Finally - let's connect the click button in the DOM to the Javascript function we've just created. In the template, add a click handler to the md-button to call the function `markImportant()` by adding ` @click="markImportant()"` to the `<md-button> tag 
423 ```html
424     <!-- TODO - SVG for use in Lab3 -->
425     <md-button class="important-flag" @click="markImportant()">
426         <svg :class="{'red-flag': todoItem.important}"  height="24" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" ><path d="M0 0h24v24H0z" fill="none"/><path d="M14.4 6L14 4H5v17h2v-7h5.6l.4 2h7V6z"/></svg>
427     </md-button>
428 ```
429
430 3. The previously failing tests should have started to pass now. With this work done, let's commit our code. On the terminal, run 
431 ```bash
432 $ git add .
433 $ git commit -m "Implementing the todoitem flag"
434 $ git push
435 ```
436
bc581a 437 3. If we try to use our important flag, we should see it's still not behaving as expected; this is because we're not updating the state of the app in response to the click event. We need to implement the `actions` and `mutations` for our feature. Let's start with the tests. Open the `tests/unit/javascript/actions.spec.js` and navigate to the bottom of the file. Our action should should commit the `MARK_TODO_IMPORTANT` to the mutations. Scroll to the end of the test file and implement the skeleton test by adding `expect(commit.firstCall.args[0]).toBe("MARK_TODO_IMPORTANT");` as the assertion.
5285f8 438 ```javascript
D 439   it("should call MARK_TODO_IMPORTANT", done => {
440     const commit = sinon.spy();
441     state.todos = todos;
442     actions.updateTodo({ commit, state }, { id: 1, important: true }).then(() => {
443         // TODO - test goes here!
444         expect(commit.firstCall.args[0]).toBe("MARK_TODO_IMPORTANT");
445         done();
446     });
447   });
448 ```
449
bc581a 450 3. We should now have more failing tests, let's fix this by adding the call from our action to the mutation method. Open the `src/store/actions.js` file and scroll to the bottom to the `updateTodo()` method. Complete the if block by adding `commit("MARK_TODO_IMPORTANT", i);` as shown below.
5285f8 451 ```javascript
D 452 updateTodo({ commit, state }, { id, important }) {
453     let i = state.todos.findIndex(todo => todo._id === id);
454     if (important) {
455         // TODO - add commit imporant here!
456         commit("MARK_TODO_IMPORTANT", i);
457     } else {
458         commit("MARK_TODO_COMPLETED", i);
459     }
460 ```
461
462 3. Finally, let's implement the `mutation` for our feature. Again, starting with the tests..... Open the `tests/unit/javascript/mutations.spec.js`. Our mutation method is responsible to toggling the todo's `important` property between true and 
463 false. Let's implement the tests for this functionality by setting imporant to be true and calling the method expecting the inverse and setting it to false and calling the method expecting the inverse. 
464 ```javascript
465   it("it should MARK_TODO_IMPORTANT as false", () => {
466     state.todos = importantTodos;
467     // TODO - test goes here!
468     mutations.MARK_TODO_IMPORTANT(state, 0);
469     expect(state.todos[0].important).toBe(false);
470   });
471
472   it("it should MARK_TODO_IMPORTANT as true", () => {
473     state.todos = importantTodos;
474     // TODO - test goes here!
475     state.todos[0].important = false;
476     mutations.MARK_TODO_IMPORTANT(state, 0);
477     expect(state.todos[0].important).toBe(true);
478   });
479 ```
480
481 3. With our tests running and failing, let's implement the feature to their spec. Open the `src/store/mutations.js` and add another function called `MARK_TODO_IMPORTANT` below the `MARK_TODO_COMPLETED` to toggle `todo.important` between true and false.
482 ```javascript
483   MARK_TODO_IMPORTANT(state, index) {
484     console.log("INFO - MARK_TODO_IMPORTANT");
485     state.todos[index].important = !state.todos[index].important;
486   }
487 ```
488
489 3. All our tests should now be passing. On the watch tab where they are running, hit `u` to re-run all tests and update any snapshots.
490
491 3. With all our tests now passing, let's commit our code. On the terminal, run
492 ```bash
493 $ git add .
494 $ git commit -m "Implementing the store and actions"
495 $ git push
496 ```
497
498 3. Before running a build in Jenkins, let's add our tests and code to the develop branch
499 <p class="tip">
500 NOTE - At this point in a residency we would peer review the code before pushing it to develop or master branch!
501 </p>
502 ```bash
503 $ git checkout develop
504 $ git merge feature/important-flag
505 $ git push --all
506 ```
507
508 3. Run a build in Jenkins. We should see the test trend increase as we've added more tests. Validate the flag is working as expected.
bc2216 509
D 510 #### Part 1c - Create todolist e2e tests
511
5285f8 512 3.  TODO !!
43f2f2 513
f6d2bd 514 ---
43f2f2 515
D 516 ## Extension Tasks
f6d2bd 517
43f2f2 518 > _Ideas for go-getters. Advanced topic for doers to get on with if they finish early. These will usually not have a solution and are provided for additional scope._
D 519
f6d2bd 520 * Add Auth to your application
D 521 * Do some other stuff
43f2f2 522
D 523 ## Additional Reading
f6d2bd 524
43f2f2 525 > List of links or other reading that might be of use / reference for the exercise
D 526
527 ## Slide links
f6d2bd 528
D 529 > link back to the deck for the supporting material