| commit | author | age | ||
| 43f2f2 | 1 | # Exercise Title |
| D | 2 | |
| bc2216 | 3 | > The purpose of this lab is to develop and validate a new feature; and to promote the assured feature to production. The user story for our new feature is as follows |
| f6d2bd | 4 | |
| D | 5 | --- |
| 43f2f2 | 6 | |
| D | 7 | ## Learning Outcomes |
| f6d2bd | 8 | |
| 43f2f2 | 9 | As a learner you will be able to |
| f6d2bd | 10 | |
| D | 11 | * Do thing 1 |
| 12 | * Do thing 2 | |
| 13 | * Do thing 3 | |
| 43f2f2 | 14 | |
| D | 15 | ## Tools and Frameworks |
| f6d2bd | 16 | |
| 43f2f2 | 17 | > Name of tool - short description and link to docs or website |
| D | 18 | |
| f6d2bd | 19 | 1. [Jenkins](https://jenkins.io/) - OpenSource build automation server; highly customisable through plugins |
| D | 20 | 1. [Ansible]() - blah blah ... |
| 43f2f2 | 21 | |
| D | 22 | ## Big Picture |
| f6d2bd | 23 | |
| 43f2f2 | 24 | This exercise begins cluster containing blah blah |
| D | 25 | |
| f6d2bd | 26 | --- |
| 43f2f2 | 27 | |
| D | 28 | ## 10,000 Ft View |
| f6d2bd | 29 | |
| 43f2f2 | 30 | > This should contain the goal of the exercise; with enough information that advanced learners could use this to build the exercise without much guidance. The information here |
| D | 31 | |
| f6d2bd | 32 | | StoryID: DO421 | As a doer I want to mark todos as important so that I can keep track of and complete high prirority todos first | |
| D | 33 | | ------------------- | --------------------------------------------------------------------------------------------------------------- | |
| 34 | | Acceptance Criteria | | |
| 35 | ||
| 36 | priority: | |
| 37 | should be doable with a single click | |
| 38 | should add a red flag against the todo when marked important | |
| 39 | should remove the red colour flag on the flag when important removed | |
| 40 | should not affect existing todos | |
| 41 | On page load: | |
| 42 | should display existing todos that are not marked important | |
| 43 | should display existing todos that are marked important with an red flag | |
| 43f2f2 | 44 | |
| D | 45 | ## Step by Step Instructions |
| f6d2bd | 46 | |
| 43f2f2 | 47 | > This is a fairly structured guide with references to exact filenames and sections of text to be added. Include pictures and code snippets where appropriate. Rule of thumb is learners are dumb.... so over describe _why_ we're doing things |
| D | 48 | |
| f6d2bd | 49 | ### Part 1 - Tests in our Pipeline |
| D | 50 | |
| bc2216 | 51 | > _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 | 52 | |
| bc2216 | 53 | #### Part 1a - Unit tests |
| D | 54 | |
| f6d2bd | 55 | 2. TODO - show tests running locally etc (fe and api) |
| bc2216 | 56 | |
| f6d2bd | 57 | 3. TODO - add tests to jenkins with screenshots etc. |
| bc2216 | 58 | |
| D | 59 | #### Part 1b - End to End tests (e2e) |
| 60 | ||
| f6d2bd | 61 | 2. Add new part to the dev pipeline (`dev-todolist-fe-e2e`) |
| bc2216 | 62 | |
| f6d2bd | 63 | 3. Add tests and reports to Jenkins |
| bc2216 | 64 | |
| D | 65 | ### Part 2 - Our App's new feature |
| f6d2bd | 66 | |
| bc2216 | 67 | > _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 | 68 | |
| 69 | // TODO - OUR USER STORY SHOULD GO HERE ! | |
| 70 | ||
| f6d2bd | 71 | #### Part 1a - Create todolist-api tests |
| bc2216 | 72 | |
| f6d2bd | 73 | > Using [Mocha](https://mochajs.org/) as our test runner; we will now write some tests for backend functionality to persist our important-flag |
| D | 74 | |
| 75 | 3. Create a new branch in your `todolist-api` app for our feature and push it to the remote | |
| 76 | ||
| bc2216 | 77 | ```bash |
| D | 78 | $ git checkout -b feature/important-flag |
| 79 | $ git push -u origin feature/important-flag | |
| 43f2f2 | 80 | ``` |
| D | 81 | |
| f6d2bd | 82 | 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 | 83 | ```javascript |
| 84 | describe("GET /api/todos", function() { | |
| 85 | it("should respond with JSON array", function(done) { | |
| 86 | request(app) | |
| 87 | .get("/api/todos") | |
| 88 | .expect(200) | |
| 89 | .expect("Content-Type", /json/) | |
| 90 | .end(function(err, res) { | |
| 91 | if (err) return done(err); | |
| 92 | // Test goes here | |
| 93 | res.body.should.be.instanceof(Array); | |
| 94 | done(); | |
| 95 | }); | |
| 96 | }); | |
| 97 | }); | |
| 98 | ``` | |
| 99 | where: | |
| 100 | * `describe` is used to group tests together into a collection asserting some feature; for example the get all todos api. | |
| 101 | * `it` is an individual test statement and should contain an `expect` or a `should` statement asserting behaviour of the API under test. | |
| 102 | * `request` is a library for making http calls to the api. | |
| 103 | * `.expect(200)` asserts the HTTP Return Code | |
| 104 | * `res.body.should.be.instanceof(Array);` is the actual test call | |
| 105 | * `done();` tells the test runner that `mocha` has finished execution. This is needed as the http calls are asynchronous. | |
| 43f2f2 | 106 | |
| f6d2bd | 107 | 4. 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 . |
| D | 108 | |
| 109 | 4. Before writing our test; let's first make sure all the existing tests are passing. | |
| 110 | ```bash | |
| 111 | $ npm run test | |
| 112 | ``` | |
| 113 | ||
| 114 | 4. 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: | |
| 115 | * Edit the `it("should ...")` to describe the imporant flag we're testing | |
| 116 | * Edit the `.send()` to include `important: true` property | |
| 117 | * Add a new test assertion to check that `res.body.important` is `true` below the `// YOUR TEST GO HERE` line. | |
| 118 | ```javascript | |
| 119 | it("should mark todo as important and persist it", function(done) { | |
| 120 | request(app) | |
| 121 | .put("/api/todos/" + todoId) | |
| 122 | .send({ title: "LOVE endpoint/server side testing!", completed: true, important: true }) | |
| 123 | .expect(200) | |
| 124 | .expect("Content-Type", /json/) | |
| 125 | .end(function(err, res) { | |
| 126 | if (err) return done(err); | |
| 127 | res.body.should.have.property("_id"); | |
| 128 | res.body.title.should.equal("LOVE endpoint/server side testing!"); | |
| 129 | // YOUR TEST GO HERE | |
| 130 | res.body.important.should.equal(true); | |
| 131 | done(); | |
| 132 | }); | |
| 133 | }); | |
| 134 | ``` | |
| 135 | ||
| 136 | 4. Run your test. It should fail. | |
| 137 | ```bash | |
| 138 | $ npm run test | |
| 139 | ``` | |
| 140 |  | |
| 141 | ||
| 142 | 4. 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. | |
| 143 | ```javascript | |
| 144 | const TodoSchema = new Schema({ | |
| 145 | title: String, | |
| 146 | completed: Boolean, | |
| 147 | important: Boolean | |
| 148 | }); | |
| 149 | ``` | |
| 150 | ||
| 151 | 4. With your changes to the Database schema updated; re-run your tests. | |
| 152 | ```bash | |
| 153 | $ npm run test | |
| 154 | ``` | |
| 155 | ||
| 156 | 4. Commit your code to the `feature/important-flag` branch and then merge onto the `develop` branch as follows | |
| 157 | <p class="tip"> | |
| 158 | NOTE - At this point in a residency we would peer review the code before pushing it to develop or master branch! | |
| 159 | </p> | |
| 160 | ```bash | |
| 161 | $ git add . | |
| 162 | $ git commit -m "ADD backend schema updates" | |
| 163 | $ git checkout develop | |
| 164 | $ git merge feature/important-flag | |
| 165 | $ git push --all | |
| 166 | ``` | |
| 167 | ||
| 168 | #### Part 1b - Create todolist-fe tests | |
| 169 | ||
| 170 | 3. Create a new branch in your `todolist-fe` app for our feature and push it to the remote | |
| 171 | ||
| 172 | ```bash | |
| 173 | $ git checkout -b feature/important-flag | |
| 174 | $ git push -u origin feature/important-flag | |
| 175 | ``` | |
| bc2216 | 176 | |
| D | 177 | #### Part 1c - Create todolist e2e tests |
| 178 | ||
| f6d2bd | 179 | 3. TODO |
| 43f2f2 | 180 | |
| f6d2bd | 181 | --- |
| 43f2f2 | 182 | |
| D | 183 | ## Extension Tasks |
| f6d2bd | 184 | |
| 43f2f2 | 185 | > _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 | 186 | |
| f6d2bd | 187 | * Add Auth to your application |
| D | 188 | * Do some other stuff |
| 43f2f2 | 189 | |
| D | 190 | ## Additional Reading |
| f6d2bd | 191 | |
| 43f2f2 | 192 | > List of links or other reading that might be of use / reference for the exercise |
| D | 193 | |
| 194 | ## Slide links | |
| f6d2bd | 195 | |
| D | 196 | > link back to the deck for the supporting material |
