diff --git a/.markdownlint.json b/.markdownlint.json index b7c7efb..c23c962 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -3,6 +3,7 @@ "line-length": false, "fenced-code-language": false, "commands-show-output": false, + "first-line-h1": false, "ul-indent": false, "ol-prefix": { "style": "ordered" diff --git a/02 Agile Planning.md b/02 Agile Planning.md index 6756702..78e044f 100644 --- a/02 Agile Planning.md +++ b/02 Agile Planning.md @@ -4,7 +4,7 @@ Each week you will be expected to complete a series of lab activities. You will Start by reading the [assignment brief](README.md) carefully and discussing it with the rest of your team to make sure you all share a common understanding (what psychological principle are we addressing?). If you have any questions at this stage make sure to discuss then with your client (Lab Supervisor). -## Introduction to Agile +## 1 Introduction to Agile During your lecture you were introduced to the principles behind agile development. @@ -13,7 +13,7 @@ During your lecture you were introduced to the principles behind agile developme 3. If the _scope_ is not fixed how can you manage customer expectations? 4. How would you explain agile methodologies to the customer? -## Domain Modelling +## 2 Domain Modelling Now its time to meet with your customer and start planning the product. The first step is to draw a domain model. This will be quite large and complex so you should use either a whiteboard or flipchart paper. @@ -25,7 +25,7 @@ Now its time to meet with your customer and start planning the product. The firs 3. Discuss any questions with the client (Lab Supervisors) to make sure your domain model accurately reflects their understanding of the scope of the system. 4. Repeat this process until you have a complete _domain model_, invite the client over and walk through this to make sure it is correct (matches the customer's expectations). -## Requirements Gathering +## 3 Requirements Gathering Meet with your client (see note at the top of this worksheet) and work with them to identify the features they want the product to provide. Record these because you will be referring back to them during the planning and development process. Make sure these are clear, unambigous and consistent. @@ -56,7 +56,9 @@ Now work with your client to apply **MoSCoW** rules so that these requirements a Can you identify the _functional_ and _non-functional_ requirements in these user stories? -## Agile Roadmap +---- + +## 4 Agile Roadmap This activity should be carried out with the client. At the end of each step take a photograph of your roadmap, this will be useful when writing up your reflective report. @@ -68,7 +70,25 @@ This activity should be carried out with the client. At the end of each step tak You now have a product roadmap. Because your client has been actively involved in the process they will be happy with your plans and because the development team were also involved, they will also fully understand not only what needs to be done but also why. This roadmap is a live document and will be updated on a regular basis. In a permanent lab this would be left on view at all times (radiator vs icebox). -## Documentation + +## 5 High-Level Architecture + +There is a lot of planning to be carried out before you can start development. Using both your _Domain Model_ and _User Story Map_, start to plan the architecture of the product you will be developing. This architecture needs to be [evolutionary](https://www.thoughtworks.com/books/building-evolutionary-architectures) to allow for changes and support the agile development process you will be using. You should evaluate a number of architectural design patterns including: + +1. publish-subscribe +2. model-view-controller +3. web apis + +why is the _n-tier architecture_ poorly suited to agile development approaches? + +## 6 Data Storage + +Analyse the data storage requirements and decide: + +1. What _type_ of database is best suited (relational, document, graph, etc.) +2. What database technology will be used (MySQL, Redis, Mongo, Neo4J, etc.) + +## 7 Documentation As a group decide on the tools you will be using to capture project documentation. diff --git a/03 Architecture.md b/03 Architecture.md deleted file mode 100644 index c422e99..0000000 --- a/03 Architecture.md +++ /dev/null @@ -1,115 +0,0 @@ -# Architecture - -Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. - -You should refer to [this week's presentation](https://drive.google.com/open?id=1GUZTf_4yCVUBWiOS3ACQ8ngkEFak7mZy9lzYwDWePq0). - -In this worksheet you will be carrying out the initial planning which needs to take place before the first _sprint_ which will be next week. This stage is often referred to as **sprint zero**. - -## 1 Reviewing the CPD Plan - -Back in the first lab each member of your team created a **continous professional development** (CPD) plan where they identified the skills they needed to learn before the first sprint. Since the first sprint starts next week its time to review each of the plans. Split into pairs (or groups of 3) and within each group, print out copies of the plans and go through them, checking off any parts that have been completed and agreeing a suitable date (and some resources) to ensure each member of the team is ready for the first sprint. - -## 2 High-Level Architecture - -There is a lot of planning to be carried out before you can start development. Using both your _Domain Model_ and _User Story Map_, start to plan the architecture of the product you will be developing. This architecture needs to be [evolutionary](https://www.thoughtworks.com/books/building-evolutionary-architectures) to allow for changes and support the agile development process you will be using. You should evaluate a number of architectural design patterns including: - -1. publish-subscribe -2. model-view-controller -3. web apis - -why is the _n-tier architecture_ poorly suited to agile development approaches? - -## 2 Data Storage - -Analyse the data storage requirements and decide: - -1. What _type_ of database is best suited (relational, document, graph, etc.) -2. What database technology will be used (MySQL, Redis, Mongo, Neo4J, etc.) - -## 3 Deciding on the Technology Stack - -During this module you will be working in a team to develop a sophisticated suite of tools using a variety of different languages and platforms. It is assumed that you already have the required programming skills... - -You should now choose ap appropriate technology stack, making sure you understand the key technologies such as Web APIs and MQTT. By this stage your team should have a clear idea as to what needs to be developed, time for an honest team discussion: - -1. Are there any skills required to complete the project that need working on? -2. Are there any potential issues with building any parts of the product? -3. Identify the development platform - 1. What will be your primary development language? - 2. What frameworks will your team be using? - 3. Make sure you are comfortable with the mechanics of writing automated tests for your chosen language including testing async code and creating mocks: - 1. [UnitTest](https://docs.python.org/3/library/unittest.html) for Python - 2. [JUnit](http://junit.org) for Java - 3. [Jasmine](http://jasmine.github.io) for JavaScript - 4. Microsoft [Unit Test Framework](https://msdn.microsoft.com/en-us/library/hh598960.aspx) for .NET - 5. XCUnit for Swift - -Any skills shortage should be added to the **Continuous Professional Development** (CDP) plans for the appropriate team members. - -## 4 Team Organisation - -Now you need to organise your team in preparation for the first sprint which will start next week. Base your discussions on the first sprint identified in the _User Story Map_: - -1. Based on your skills audit, divide the team into different groups to tackle the different tiers in your solution. -2. Each group should map out how they will achieve the first user story, this should include: - 1. The language they will be using and why. - 2. The editor/IDE to be used. - -## 5 Technical Preparation - -1. setting up the development workstations: - 1. installing the software needed. - 2. building simple hello-world programs to check development environment is set up. -2. building and configuring any test servers and platforms -3. configuring GitHub: - 1. making sure everyone in the team can log in! - 2. creating a team in the correct organisation on GitHub. - 3. creating enough correctly named private repositories. - 4. adding the team to each of these so everyone has access to all project repositories. - -Before next week you need to make sure the team have all the required skills and have hacked together some code to prove that everything is solveable. - -## 6 GitLab - -In previous modules you have been using the GitHub Enterprise repository within the University but there for this one you will be using [GitLab](https://gitlab.com). As part of this week's labs you should configure GitLab for your team so you are ready to start development next week. - -1. Everyone needs to create accounts on the [GitLab](https://about.gitlab.com) server. -2. Upload a head and shoulders photo of yourself into your GitHub profile so that everyone knows who you are. -3. Each organisation should be set up as a [group](https://gitlab.com/dashboard/groups) which is used to organise your repositories, set one up now for your team. - - Create and upload an **avatar** for the group using the **Settings** tab. -4. Use the **Members** tab to add the team members to your group, assigning appropriate permissions (note that the permissions are _not_ the same as those used in GitHub so make sure you understand these clearly). -5. Create repositories for each part of the project, using a logical naming convention. - - Create and upload an **avatar** for each repository using the **Settings** tab. -6. Clone the repositories onto your development workstations. -7. Update the local `git config` in each of you cloned repositories: - 1. Navigate to the cloned repository. - 2. update your name `git config user.name "John Doe"` and email `git config user.email "johndoe@gmail.com"`. These must match those you used when creating your GitLab account. - 3. Update the default commit message editor from `vi` to `nano` using `git config core.editor "nano"` - 4. check the _local config_ `less .git/config` which should show you that you have updated the local settings. - -Here is a typical `.git/config` file: - -``` -[core] - repositoryformatversion = 0 - filemode = true - bare = false - logallrefupdates = true - ignorecase = true - precomposeunicode = true - editor = nano -[remote "origin"] - url = https://gitlab.com/team-fox/api.git - fetch = +refs/heads/*:refs/remotes/origin/* -[user] - name = John Doe - email = johndoe@gmail.com -``` - -## 7 Interacting with Git - -The main way you should use to work with Git are the _shell commands_ you enter using the _terminal_. Whilst you should be comfortable using these commands you might want to use a more graphical tool for day-to-day Git operations. There are many options however you should investigate: - -- Code editor Git integration: most modern code editors such as [Visual Studio Code](https://code.visualstudio.com) either come preconfigured with Git integration or it can be added as a plugin. These tools, whilst ideal for basic git work don't have the capability to run the more powerful commands. -- Standalone Git tools: whilst there are a lot of these, many (such as the one available from GitHub) are not easy to use and you may cause issues with your repository. One of the ones recommended is [GitKraken](https://www.gitkraken.com) which although has a cost attached is free for academic use. \ No newline at end of file diff --git a/03 Sprint Planning.md b/03 Sprint Planning.md new file mode 100644 index 0000000..e5a511a --- /dev/null +++ b/03 Sprint Planning.md @@ -0,0 +1,155 @@ + +# Sprint Planning + +Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. + +You should refer to [this week's presentation](https://drive.google.com/open?id=1GUZTf_4yCVUBWiOS3ACQ8ngkEFak7mZy9lzYwDWePq0). + +In this worksheet you will be carrying out the initial planning which needs to take place before the first _sprint_ which will be next week. This will allow you to focus next week on the development of good quality code. + +## 1 Reviewing the CPD Plan + +Back in the first lab each member of your team created a **continous professional development** (CPD) plan where they identified the skills they needed to learn before the first sprint. Since the first sprint starts next week its time to review each of the plans. Split into pairs (or groups of 3) and within each group, print out copies of the plans and go through them, checking off any parts that have been completed and agreeing a suitable date (and some resources) to ensure each member of the team is ready for the first sprint. + +## 2 Sprint Planning + +As a team: + +1. Identify who will be the **Scrum Master** and who will be the **Product Owner**. +2. Ideally with the client present, take the first user story from the top row of your user story map: + 1. The product owner describes it from the user's perspective + 2. Discusses how it can be implemented and work collaboratively on a whiteboard/flipchart to define it's UI until the client/product owner is satisfied/ + 3. Explain the success criteria (how will the team know they have completed the story implementation. +3. Once the client has left: + 1. Break the story into the component tasks and write these on sticky notes. + 2. Use planning poker to estimate how many hours each task will take. + - If the estimated time for a task is longer than 4 hours, consider splitting the task down. + 3. Add them to the left column of your Kanban board. + 4. Finally the _Scrum Master_: + 1. adds up the estimated durations for the tasks on the Kanban board and + 2. draws out a burndown chart: + 1. The X axis should show the days in the sprint. + 2. the Y axis should show the combined duration. + 3. draws a staight line from the top of the Y axis to the end of the X axis to indicate the optimal burn rate. + +### 2.1 The Kanban Board + +For this first sprint, your Kanban board should have a row for each of the user stories you have chosen to deliver and 4 columns as shown: + +``` +╔═════════╦════════════════╦════════════════╦════════════════╦════════════════╗ +║ Story ║ To Do ║ Planning ║ Implementation ║ Done ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╚═════════╩════════════════╩════════════════╩════════════════╩════════════════╝ +``` + +At the start of the sprint, all tasks should be in the **To Do**. By the end of the sprint, all tasks should be in the **Done** column. + +### 2.2 The Burndown Chart + +Here is an example of a burndown chart showing the line of optimal development. In this example the sprint lasts from Mon to Fri and there are an estimated 40 hours of development. It shows that the optimum burn rate would be 10 hours per day. + +``` + 40 ║* + ║ * + 30 ║ * + ║ * + 20 ║ * + ║ * + 10 ║ * + ║ * + 00 ║ * + ╚══════════════════════════ + M T W T F +``` + +## 3 GitLab + +In previous modules you have been using the GitHub Enterprise repository within the University but there for this one you will be using [GitLab](https://gitlab.com). As part of this week's labs you should configure GitLab for your team so you are ready to start development next week. + +1. Everyone needs to create accounts on the [GitLab](https://about.gitlab.com) server. +2. Upload a head and shoulders photo of yourself into your GitLab profile so that everyone knows who you are. +3. Each organisation should be set up as a [group](https://gitlab.com/dashboard/groups) which is used to organise your repositories, set one up now for your team. + - Create and upload an **avatar** for the group using the **Settings** tab. +4. Use the **Members** tab to add the team members to your group, assigning appropriate permissions (note that the permissions are _not_ the same as those used in GitHub so make sure you understand these clearly). +5. Create repositories for each part of the project, using a logical naming convention and upload an **avatar** for each repository using the **Settings** tab: + 1. A repository for the microcontroller code. + 2. A repository for yor API code. + 3. A repository for each of your clients (web, iOS, android) depending on the choices made by your team. +6. Clone the repositories onto your development workstations. +7. Update the local `git config` in each of you cloned repositories: + 1. Navigate to the cloned repository. + 2. update your name `git config user.name "John Doe"` and email `git config user.email "johndoe@gmail.com"`. These must match those you used when creating your GitLab account. + 3. Update the default commit message editor from `vi` to `nano` using `git config core.editor "nano"` + 4. check the _local config_ `less .git/config` which should show you that you have updated the local settings. + +Here is a typical `.git/config` file: + +``` +[core] + repositoryformatversion = 0 + filemode = true + bare = false + logallrefupdates = true + ignorecase = true + precomposeunicode = true + editor = nano +[remote "origin"] + url = https://gitlab.com/team-fox/api.git + fetch = +refs/heads/*:refs/remotes/origin/* +[user] + name = John Doe + email = johndoe@gmail.com +``` + +The `less` command allows you to view and navigate the contents of a file. You should check the [documentation](https://en.wikipedia.org/wiki/Less_(Unix)) to learn how to navigate up and down the file and (most importantly) how to quit! + +### 3.1 Interacting with Git + +The main way you should use to work with Git are the _shell commands_ you enter using the _terminal_. Whilst you should be comfortable using these commands you might want to use a more graphical tool for day-to-day Git operations. There are many options however you should investigate: + +- Code editor Git integration: most modern code editors such as [Visual Studio Code](https://code.visualstudio.com) either come preconfigured with Git integration or it can be added as a plugin. These tools, whilst ideal for basic git work don't have the capability to run the more powerful commands. +- Standalone Git tools: whilst there are a lot of these, many (such as the one available from GitHub) are not easy to use and you may cause issues with your repository. One of the ones recommended is [GitKraken](https://www.gitkraken.com) which although has a cost attached is free for academic use. + +### 3.1 Ignoring Files + +As you develop your code you will be adding and generating files that have no place in the repository. These might include: + +1. Third-party libraries. +2. Compiled binary files. + +Create a file in the repository directory, this file should be called `.gitignore` (notice the leading full stop character). In it you list all the directories and files that should be ignored by Git. here is a simple example: + +``` +node_modules/ +libraries/ +*.exe +*.hex +.DS_Store +``` + +In this example we want git to ignore any directories called `node_modules/` or `libraries/` as well as any files with an `.exe` or `.hex` file extension. It also ignores the hidden files that MacOS uses to organise the directories. + +## 4 Next Steps + +You are now ready to conduct your first sprint which will start first thing on Monday morning. Make sure you clear your schedules as much as possible and as a group decide where you will meet up for your first daily standup early on Monday morning. The instructions for conducting this meeting are detailed in the next worksheet. + +### 4.1 Places to Meet + +For an effective sprint you need to be meeting and working together all next week. Suggestions for suitable places to meet could be: + +1. The cafe in the EEC building or in town. +2. The seating in the Student Hub (beanbags or cubicles). or in the coffee shop or eating areas. diff --git a/04 Agile Development.md b/04 Agile Development.md deleted file mode 100644 index aea4dcc..0000000 --- a/04 Agile Development.md +++ /dev/null @@ -1,136 +0,0 @@ - -# Agile Development - -Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. - -You should refer to [this week's presentation](https://drive.google.com/open?id=1nAEwEr7C6VTcRLSTnGqzhDvFzvek8fcKZuNHcjikBBs). - -## 1 Sprint Planning - -As a team: - -1. Identify who will be the **Scrum Master** and who will be the **Product Owner**. -2. Ideally with the client present, take the first user story from the top row of your user story map: - 1. The product owner describes it from the user's perspective - 2. Discusses how it can be implemented and work collaboratively on a whiteboard/flipchart to define it's UI until the client/product owner is satisfied/ - 3. Explain the success criteria (how will the team know they have completed the story implementation. -3. Once the client has left: - 1. Break the story into the component tasks and write these on sticky notes. - 2. Use planning poker to estimate how many hours each task will take. - - If the estimated time for a task is longer than 4 hours, consider splitting the task down. - 3. Add them to the left column of your Kanban board. - 4. Finally the _Scrum Master_: - 1. adds up the estimated durations for the tasks on the Kanban board and - 2. draws out a burndown chart: - 1. The X axis should show the days in the sprint. - 2. the Y axis should show the combined duration. - 3. draws a staight line from the top of the Y axis to the end of the X axis to indicate the optimal burn rate. - -### 1.1 The Kanban Board - -For this first sprint, your Kanban board should have 4 columns as shown: -``` -╔════════════════╦════════════════╦════════════════╦════════════════╗ -║ To Do ║ Planning ║ Implementation ║ Done ║ -╟────────────────╫────────────────╫────────────────╫────────────────╢ -║ ┌────────┐ ║ ║ ║ ║ -║ │ │ ║ ║ ║ ║ -║ └────────┘ ║ ║ ║ ║ -║ ┌────────┐ ║ ║ ║ ║ -║ │ │ ║ ║ ║ ║ -║ └────────┘ ║ ║ ║ ║ -║ ┌────────┐ ║ ║ ║ ║ -║ │ │ ║ ║ ║ ║ -║ └────────┘ ║ ║ ║ ║ -╚════════════════╩════════════════╩════════════════╩════════════════╝ -``` - -At the start of the sprint, all tasks should be in the first column. By the end of the sprint, all tasks should be in the last column. - -### 1.2 The Burndown Chart - -Here is an example of a burndown chart showing the line of optimal development. In this example the sprint lasts from Mon to Fri and there are an estimated 40 hours of development. It shows that the optimum burn rate would be 10 hours per day. -``` - 40 ║* - ║ * - 30 ║ * - ║ * - 20 ║ * - ║ * - 10 ║ * - ║ * - 00 ║ * - ╚══════════════════════════ - M T W T F -``` - -## 2 Conducting the Sprint - -During this first sprint, your development team will need to carry out a **Daily Standup meeting** every morning. Before this meeting, the _Scrum Master_ should: - -1. Check the _Kanban board_ is up to date. -1. add up the hours for all the tasks remaining incomplete on the Kanban board and using this to update the _Burndown Chart_. -``` -╔════════════════╦════════════════╦════════════════╦════════════════╗ -║ To Do ║ Planning ║ Implementation ║ Done ║ -╟────────────────╫────────────────╫────────────────╫────────────────╢ -║ ┌────────┐ ║ ║ ┌────────┐ ║ ┌────────┐ ║ -║ │ │ ║ ║ │ │ ║ │ │ ║ -║ └────────┘ ║ ║ └────────┘ ║ └────────┘ ║ -║ ║ ║ ║ ║ -║ ║ ║ ║ ║ -║ ║ ║ ║ ║ -║ ║ ║ ║ ║ -║ ║ ║ ║ ║ -║ ║ ║ ║ ║ -╚════════════════╩════════════════╩════════════════╩════════════════╝ -From this Kanban board you can see that one of the tasks has been -completed (and so these hours come off the burndown chart). -One of the tasks has been started but is not yet complete (this stays -on the burndown chart) -The last task has not been fully planned out, this task should be a -priority until the next daily standup. -``` -``` - 40 ║* - ║ * o - 30 ║ * o As you can see from this example, by the Wednesday - ║ * meeting the team are behind schedule. They need to - 20 ║ * identify *why* this has happened: - ║ * * poor estimation? - 10 ║ * * one of the teams has hit a problem? - ║ * * members of the team off sick? - 00 ║ * - ╚══════════════════════════ Can they make up the work by the Friday? - M T W T F -``` - -During the meeting: - -1. The Scrum Master reviews the burndown chart and tells the team whether they are ahead or behind schedule: -2. Now each member: - 1. explains what they have achieved since the last daily standup meeting. - 2. uses the Kanban board to identify the tasks they will work on until the next meeting (tomorrow), flags with the team responsible and moves these forward on the board. - 3. Describes any technical challenges that are holding back development work. - -If any problems were identified during the standup these will need to be resolved by the appropriate team immediately **after** the daily standup. Make sure the resolution is explained to the _Scrum Master_ before continuing work. - -Now each team have tasks assigned and will need to implement these before the next daily standup. - -## 3 Review Meeting - -You will be given a date for the review meeting, this will typically be a week after the start of the sprint. During this meeting you will be expected to do a local demo of the software you built during the sprint so make sure you are prepared. - -1. The **Product Owner** reads the user story/storys completed during the sprint. -2. The **Scrum Master** demonstrates the new features to the client. -3. Any bugs identified are added to the Kanban board to be addressed in the next sprint. - -The team then move on to the next _sprint planning meeting_ whilst the client is present. - -## 4 Retrospective - -Each week the development team should meet up (without the client) and ask each member of the team to identify: - -1. What they should continue to do (existing good practice) -2. What they should **start** doing (new good practice) -2. What they should **stop** doing (eliminiate bad practices) diff --git a/04 Effective Sprints [1].md b/04 Effective Sprints [1].md new file mode 100644 index 0000000..cae8387 --- /dev/null +++ b/04 Effective Sprints [1].md @@ -0,0 +1,75 @@ + +# Agile Development + +Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. + +This week is very important. You will be conducting your first sprint. To do this you will be expected to meet every morning to conduct your daily standup meeting (see below on how to do this) and will be expected to spend the rest of the day in your teams completing the work agreed. + +You have already decided on who will be the **Scrum master** and the **product owner** and will already have prepared the **Kanban board** and **Burndown chart** which means you can dive straight into the coding. + +You should refer to [this week's presentation](https://drive.google.com/open?id=1nAEwEr7C6VTcRLSTnGqzhDvFzvek8fcKZuNHcjikBBs) as well as [this short video from IBM](https://youtu.be/oHcmLKroPqw). + +## 1 Conducting the Sprint + +During this first sprint, your development team will need to carry out a **Daily Standup meeting** every morning. Before this meeting, the _Scrum Master_ should: + +1. Check the _Kanban board_ is up to date. +2. Add up the calculated hours for all the tasks in the **Done** column on the Kanban board and use this to update the _Burndown Chart_. + +``` +╔═════════╦════════════════╦════════════════╦════════════════╦════════════════╗ +║ Story ║ To Do ║ Planning ║ Implementation ║ Done ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ║ ┌────────┐ ║ ┌────────┐ ║ +║ ║ │ │ ║ ║ │ │ ║ │ │ ║ +║ ║ └────────┘ ║ ║ └────────┘ ║ └────────┘ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ +║ ║ │ │ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ +╟─────────╫────────────────╫────────────────╫────────────────╫────────────────╢ +║ ║ ┌────────┐ ║ ┌────────┐ ║ ┌────────┐ ║ ┌────────┐ ║ +║ ║ │ │ ║ │ │ ║ │ │ ║ │ │ ║ +║ ║ └────────┘ ║ └────────┘ ║ └────────┘ ║ └────────┘ ║ +║ ║ ║ ║ ┌────────┐ ║ ┌────────┐ ║ +║ ║ ║ ║ │ │ ║ │ │ ║ +║ ║ ║ ║ └────────┘ ║ └────────┘ ║ +║ ║ ║ ║ ║ ║ +╚═════════╩════════════════╩════════════════╩════════════════╩════════════════╝ +From this Kanban board you can see that there are 2 user stories being delivered. +Three of the tasks have been completed (and so these hours come off the burndown chart). +Four of the tasks have been started but are not yet complete (this stays +on the burndown chart). +The priority should be on the tasks in the implementation column to move them +to the Done column to remove then from the outstanding work and improve the +burndown rate. +``` + +``` + 40 ║* + ║ * o + 30 ║ * o As you can see from this example, by the Wednesday + ║ * meeting the team are behind schedule. They need to + 20 ║ * identify *why* this has happened: + ║ * * poor estimation? + 10 ║ * * one of the teams has hit a problem? + ║ * * members of the team off sick? + 00 ║ * + ╚══════════════════════════ Can they make up the work by the Friday? + M T W T F +``` + +During the meeting: + +1. The Scrum Master reviews the burndown chart and tells the team whether they are ahead or behind schedule: +2. Now each member: + 1. explains what they have achieved since the last daily standup meeting. + 2. uses the Kanban board to identify the tasks they will work on until the next meeting (tomorrow), flags with the team responsible and moves these forward on the board. + 3. Describes any technical challenges that are holding back development work. + +If any problems were identified during the standup these will need to be resolved by the appropriate team immediately **after** the daily standup. Make sure the resolution is explained to the _Scrum Master_ before continuing work. + +Now each team have tasks assigned and will need to implement these before the next daily standup. + +## 2 Getting Feedback + +As part of the learning process you will need to conduct one of your sprints in a lab session so that your lab supervisors can watch and provide you with feedback that you can use to improve. Discuss this with your lab supervisors and agree on the session you will attend. diff --git a/05 Advanced Git.md b/05 Advanced Git.md new file mode 100644 index 0000000..4079a12 --- /dev/null +++ b/05 Advanced Git.md @@ -0,0 +1,216 @@ + +# Advanced Git + +Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. + +You should refer to [this week's presentation](https://drive.google.com/open?id=1JmtlJWZy5Y5pFhDoggkLzaCSrbSa3plBh105nZtU2qA). + +## 1 What Will You Be Doing? + +In this third sprint you will be adopting some additional agile concepts. The focus in this sprint is to improve the overall quality of your code-base: + +1. Your team will add protection to the `master` branch to prevent developers from directly pushing to it. +2. You will be running the non-functional testing that you covered in the last worksheet to ensure you are writing high-quality code. +3. You will develop each feature in its own _feature branch_. +4. You will be implementing **pull requests** to monitor and check the code being merged into the master branch. +5. You will rebase code into your feature branches to make it easier to merge on completion. +6. You will be tagging your releases. +7. And finally you will be implementing **Git Hooks** to run tests before committing and before pushing. + +## 2 Before the Sprint + +Unlike the previous sprints there are a couple of tasks you need to carry out this week before starting. + +### 2.1 Update The Ignored Files List + +Before starting the sprint, review the contents of the GitLab repository to identify any files that should not be in the repository. These might include: + +1. Binary files +2. Third-party modules and libraries +3. Editor setting files +4. Local settings + +If you find a file it can be removed by running the following command: + +``` +$ git rm --cached file1 file2 +``` + +Once this has been done you will need to: + +1. Add the names of the files and directories to your `.gitignore` file (otherwise they will be added to the next commit! +2. Use the `git status` command to make sure Git is not picking up the files. +3. Commit the changes and push. +4. Make sure the file(s) are no longer on the GitLab repository. + +### 2.2 Configure Team Permissions + +The first step is to make sure that everyone in the team has been assigned the correct permission levels. + +1. One person in each _sub-team_ (eg, API, iOS, etc.) should be the designated **Code Owner**. +2. There are four permission levels: Guest, Developer, Reporter, Master. Everyone in the team should have developer permission. +3. The designated **Code Owner** for each repository should be given **Master** permissions. + +### 2.3 Protected Branches + +In your first sprint you all had full access to the _Master Branch_ meaning anyone in the team could commit to it and merge branches into it. As you quickly discovered this caused a lot of problems. In this sprint your team will be making the master branch into a **protected branch**, restricting who can interact with it and how. + +1. In your GitLab repositories go to `Settings > Repository` and expand the **Protected Branches** section. +2. In the **Branch** dropdown list choose `master`. +3. In the **Allowed to merge** dropdown list choose 'Masters', this will prevent except _code owners) from merging any code into this branch. +4. In the **Allowed to push** dropdown list make sure that you choose `No one`, we don't want any code to be pushed directly into this branch. + +### 2.4 Configuring the Non-Functional Tests + +In the previous week you implemented a suite of non-functional tests. Before starting this sprint make sure these are: + +1. Installed and configured correctly. +2. Run correctly (note the output you should be expecting). + + +### 2.5 Hooks + +The value generated by your team lies in the quality code they produce so you should take time to ensure this is securely stored on your remote repository (GitHub). The first step is to ensure each person in the team only has the minimum permissions needed to do their job. You have already added some security by configuring _protected branches_ in the last lab. We will now improve this. + +In the **Code Quality** worksheet you created a range of automated tests to check both _functional_ and _non-functional_ requirements. Many of these, such as the _linter_ returned a `0` on success and a non-zero if the test failed. Until now we have triggered these tests manually but, using **git hooks** these can be triggered in response to specific events. + +#### 2.5.1 Pre-Commit + +Let's use a **Git Hook** to run checks on our code before allowing us to commit. In this example git will reject any code that fails the linting test. + +Use the terminal to create a new file in the `.git/hooks/` directory called `pre-commit`. + +```shell +$ nano .git/hooks/pre-commit +``` + +You should now write a **shell script** to run the linter for your chosen language. You should already have a suitable script. Remember to include a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line to identify the _script executable_, typically on a *nix system this will be `#!/bin/sh` if the script is a _shell script_. + +Finally you need to set the script as executable. + +```shell +$ chmod +x .git/hooks/pre-commit +``` + +Lets see if this works: + +1. Introduce a linting error (warnings won't work). +2. Manually trigger the linter to check it is being picked up properly. +3. Try staging and committing, it should be rejected. +4. Fix the linting error. +5. Try staging and committing again, it should work this time. + +By setting up a number of tests in git hooks you can automatically monitor the code quality _before_ it is committed. The downside is that the more tests you include, the slower the commit process. + +#### 2.5.2 Pre-Push + +Rather than having a lot of tests that run at the commit stage you can also have tests that are triggered before the code is pushed (the push is rejected if they fail). The trick is to decide which tests should be `pre-commit` and which should be `pre-push`. This should be agreed by the team and the hooks set up before work starts. + +Have a go at setting up a `pre-push` hook. You can choose whatever test or tests you want to include in this. + + +## 3 Conducting the Sprint + +In this third sprint you will be adopting some additional agile concepts on top of all the skills you have already been using: + +1. You will be implementing non-functional testing to improve code quality. +2. You will be implementing **pull requests** to monitor and check the code being merged into the master branch. +3. You will rebase code into your feature branches to make it easier to merge on completion. +4. You will be tagging your releases. +5. And finally you will be implementing **Git Hooks** to run tests before committing and after pushing. + +### 3.1 Daily Standup Meeting + +Your development team will still need to carry out a **Daily Standup meeting** every morning. Before this meeting, the _Scrum Master_ should: + +1. Check the _Kanban board_ is up to date. +2. add up the hours for all the tasks remaining incomplete on the Kanban board and using this to update the _Burndown Chart_. + +The Scrum Master needs to make sure everyone is engaged in the process. Adopt the following policy: + +1. Everyone should be there at the agreed time. Anyone delayed must phone the Scrum Master and the meeting postponed until they are there. +2. Everyone should be standing around the information radiators (whiteboard/flipchart). +3. Phones stay in pockets. meeting paused if anyone uses a phone (they are not focussed). +4. Laptops only to be used to demonstrate functionality. + +During the meeting: + +1. The Scrum Master reviews the burndown chart and tells the team whether they are ahead or behind schedule: +2. Now each member: + 1. explains what they have achieved since the last daily standup meeting, running the **acceptance test suite** and **unit test suite** to demonstrate this. + 2. uses the Kanban board to identify the tasks they will work on until the next meeting (tomorrow), flags with the team responsible and moves these forward on the board. + 3. Describes any technical challenges that are holding back development work. + +If any problems were identified during the standup these will need to be resolved by the appropriate team immediately **after** the daily standup. Make sure the resolution is explained to the _Scrum Master_ before continuing work. + +Now each team have tasks assigned and will need to implement these before the next daily standup. + +### 3.2 The Development Process + +This is the same as in the previous sprint with the following **additions**: + +#### 3.2.1 Creating a Pull/Merge Requests + +This should be carried out only if the feature is complete and all the automated tests (functional and non-functional) pass. + +1. Click on the **Merge Requests** tab. +2. Click on the **New merge request** button. +3. The _source branch_ is the feature branch and the _target branch_ should be the master branch. +4. Click on the **Compare branches and continue** button. +5. Review the changes at the bottom of the next screen. +6. Add a title and description to the merge request, this should explain the work that has been done. +7. Click on **Submit merge request** + +### 3.2.2 Approving a Pull/Merge Request + +All requests will need to be reviewed by the **Code Owner**. + +1. The number of merge requests needing approval are shown on the **Merge Requests** tab. +2. Review the changes: + 1. Pull the branch. + 2. Review the changes (and run tests). +3. Check the **Remove source branch** box. +4. Click on the **Merge** button. + +If the code is not ready for merging you should add a comment and send it back to the development team. If the code is far from ready you can **close** the merge request. + +#### 3.2.3 Rebasing + +Rebasing allows you to unplug the base of your feature branch and replug it further down the commit tree. This allows you to integrate changes to the master branch in your feature branch in a clean way. You should carry this out on any long-running branch and it should be carried out if code has been merged to the master branch after this branch was created. + +Take a few moments to review the structure of your git repository. Open the commit graph in GitLab `Repository > Graph` or use the `git log` command to get a visual representation. + +```shell +$ git log --pretty=format:"[%cn] %h %s (%cr)" --graph +``` + +You can navigate forward a screen using <space>, back a screen using `w` and quit using `q`. + +You should identify any branches and either: + +- If the feature is complete _delete the branch_. +- If the feature is not complete, do a rebase to make sure the feature branch contains the latest code from `master`. Check out the feature branch and `git rebase master`. + +This should make your git history much easier to understand. By rebasing your feature branches they will become far easier to merge back in to the `master` branch once the feature is complete. + +## 4 After Completing a Story + +Once a story has been completed you will need to create a software **release** by adding a **git tag**. + +These are used to mark the code snapshots corresponding to the software releases, this is in the form of 3 numbers separated by periods (.) such as `v1.12.2`. There are [naming conventions](https://semver.org) you should use: + +1. The first number is the **MAJOR**. If the product is still in beta this should be `0`. It only changes if there are major changes to the software. +2. The second number is the **MINOR**. It should be incremented for each user story completed. +3. The third number records the **PATCH** and is incremented whenever a bug is fixed. + +- Go through the code in your master branch and note the 7 character _commit hash_ of the first working version of your code. After creating a tag it needs to be pushed to the remote: + +```shell +$ git tag -a v0.1.12 -m 'Describe the changes clearly, +you can use multiple lines' +$ git push origin v0.1 +``` + +These can be seen on GitLab under the `Repository > Tags` section which gives you the opportunity to download the code at that point. + +Repeat the operation for subsequent working versions of your code (typically as you complete each user story). If the release contains the **Minimum Viable Product** (MVP) the version should increment to `v1.0`. diff --git a/05 Code Quality.md b/05 Code Quality.md deleted file mode 100644 index 9b65559..0000000 --- a/05 Code Quality.md +++ /dev/null @@ -1,170 +0,0 @@ - -# Code Quality - -Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. - -You should refer to [this week's presentation](https://drive.google.com/open?id=1xy3MWh96JUdI8DiAtOUFznA0aEf4FBzp8zbIrPBtTdw). - -In this worksheet you will be critically reviewing the code your team have written and creating a suite of automated tests to ensure this is maintained to a high standard. Because these tests are directly checking your source code there are different tools for each language. - -To help you complete the labs, there are working examples for different languages in the `exercises/05_code_quality/` directory. - -## 1 Non-Functional Requirements - -Lets start by adding a suite of tests to improve the general code quality. These won't test how well the code solves the user stories. - -### 1.1 Linting - -It can be tough for development teams to format their code in a consistent way: naming of variables and constants, extra whitespace, irregular indentation, and other “sloppiness” then often leads to actual bugs in the program. - -1. Install and run a suitable linter on the source code using its default settings. - - what errors and warnings does it flag up? - - are these easily fixable? -2. Can you find a plugin for your IDE so that the errors and warnings are flagged up in your editor? - - install the plugin and make sure it is highlighting the errors and warnings. -3. Most linters are configurable through a settings file. - 1. Create a simple settings file and make sure it is being read when the linter runs. - 2. Review the rules that can be customised and, in your team, decide on the agreed set of rules. - 3. Now use the linter output to ensure your code adheres to these rules. - -Whilst strictly not part of the _linting_ process, if you are using a _compiled language_ a good test is whether each source code file **compiles** correctly! - -### 1.2 Code Duplication - -The **Don't Repeat Yourself** (DRY) principle states that you should not have duplicate code scattered around your project as it makes it harder to find and fix bugs, but how can you check this? - -There are tools for all main programming languages that can flag up duplicate code across an entire project. - -1. Install a suitable tool that supports your language. -2. Run the tool using the default settings. - - does it flag up any code duplication? - - if so, can you locate this based on the information it provides? - - can this duplication be removed? -3. Most code duplication tools can be customised either through flags or a configuration file. - 1. Look at the documentation and identify how to customise the tool. - 2. Change some settings (for example the min lines) and run the tool. - - are the results more or less useful? - 3. As a team, decide on the settings you will be using and make sure they are used consistently for the remainder of the project. - -### 1.3 Checking Dependencies - -Every time you import a library/framework into your project it gets added to the codebase which means it takes longer to run the program and the size of the code increases. For this reason you should not be importing any dependency that you don't use. - -There are dependency checkers for most languages that can flag any imported module/library/framework which is not used in the code. - -1. Install a suitable tool that supports your language. -2. Run the tool and check any warnings/errors it generates. -3. Remove the unused modules/libraries/frameworks. -4. Run the tool again and repeat until no errors are reported. - -In some languages, all dependencies have to be recorded in a configuration file such as `package.json` in the case of NodeJS scripts. In these cases, by using different flags, the tool can: - -1. Identify any packages that are defined in config file and not used. -2. Identify any packages that are installed but not recorded in the config file. - -If you are using a language that uses a config file you should run these two additional tests. - -### 1.4 Profiling - -Software profiling is a dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. - -Profiling is normally used to improve program optimization and is achieved by instrumenting either the program source code or its binary executable using a tool called a **profiler**. - -Most mainstream languages include a profiler: - -1. Learn how the profiler works for your particular language, you may find some useful information in the `exercises/05_code_quality/04_profiling/` directory. -2. Activate the profiler. -3. Run your program. - - If appropriate, use a tool such as Apache Bench to simulate a load on your system. -4. This should have generated a **tick file**. - - use a suitable **tick interpreter** to analyse this data. - - Does it reveal any useful information about your program? -5. Can you use this data to improve your program? - -## 2 Functional Requirements - -Now we have tested a range of _non-functional requirements_ its is time to write some tests to see if we have achieved the _functional requirements_. - -### 2.1 Unit Testing - -If you have never done unit testing you should take time to complete the [Testing Your Code](https://www.codecademy.com/courses/testing-your-code) exercises on [Codeacademy](https://www.codecademy.com). - -#### 2.1.1 Modularising Your Code - -It is vital that you provide a comprehensive suite of tests for your existing code. but before you can write effective unit tests you need to ensure that your code is split into a number of independent units. Each module: - -1. Should not be dependent on any other module you have written (you can have dependencies to third-part modules). -2. Should contain code that shares a similar function. -``` -╔═════╗ ╔═════╗ ╔═════╗ In this example the code in modules (A), (B) and (C) -║ A ║ ║ B ║ ║ C ║ is not dependent on any of the other modules and so -╚══╤══╝ ╚══╤══╝ ╚══╤══╝ we can write unit tests for them. - │ │ │ - │ │ │ Module (D) imports the other three modules and so - │ ┌──┴──┐ │ we can't include this module in our unit tests. - └───────────→─┤ D ├─←───────────┘ - └─────┘ -``` - -Take time to tidy up your code ready for the next step. How much of the code can you isolate in code modules and unit test? Ideally all your code (embedded, API and client(s)) needs to be modularised. - -#### 2.1.2 Writing Unit Tests - -You should now create a separate test suite for each of these code modules. The test suites are written in the same language as the code you are testing. There are unit testing suites available for all mainstream languages, use the examples in the `exercises/05_code_quality/05_unit/` directory to get you started. Whatever language you are testing: - -1. All unit tests should be kept together in a directory (typically named `spec/`). -2. Each code module should have its own test file that includes the name of the module in the format `unit-xxxx.xx`. -3. Each function/method in each module/class needs several tests: - 1. using valid data - 2. using threshold data - 3. using invalid data -4. Make sure all the tests pass at 100% - -There are examples of unit tests for multiple languages in the `/exercises/07_unit/` directory on GitHub. - -##### 2.1.2.1 Unit Testing Microcontroller Code - -One special case is writing and executing unit test on code that will eventually run on a microcontroller. There are two approaches that you should investigate and reflect on in your report: - -1. Arduino _libraries_ are written in standard C++ so, if there are no dependencies on Arduino-specific libraries you can write your unit tests using a standard testing framework. There is more information in the `exercises/05_code_quality/05_unit/cpp/` directory. -2. If you are using _Arduino-specific libaries_ you may need to test your code using an **Atmel emulator**. Again, there is more information in the same directory. - -### 2.2 Integration Testing - -Although you now have a suite of unit tests for the isolated mode modules/classes, there are some code modules/units/files that are not currently being tested. This could be for one of two reasons: - -1. They import other modules/classes. -2. They don't contains methods/functions that are _testable_ in that they don't return data (perhaps they send information to the web browser directly or return API data). - -it is quite possible to write tests for case (1) but, rather than testing the isolated module they are testing whether the module integrates with the rest of the modules (rather like testing the plumbing). We call these **integration tests** and they are written using the same tools as unit tests even though they serve a different purpose. -``` -┌─────┐ ┌─────┐ ┌─────┐ In this example the code in modules (A), (B) and (C) -│ A │ │ B │ │ C │ has already been tested using our *unit tests*. -└──┬──┘ └──┬──┘ └──┬──┘ - │ │ │ Since all the isolated business logic is in these - │ │ │ modules, the purpose of module (D) is to import - │ ╔══╧══╗ │ and integrate the functions/methods in the other - └───────────→─╢ D ╟─←───────────┘ 3 modules. We therefore write integration tests - ╚═════╝ for module (D). -``` -1. Create a testing suite for your integration module(s). These need to be saved in the same directory as your unit tests but add a different prefix, eg: `integration-xxxx.xx` -2. Write a comprehensive suite of tests to make sure the functions from the other modules are working correctly together. - -### 2.3 Code Coverage - -In the previous two sections you were told to write a _comprehensive suite of tests_, but what is _comprehensive_? Our test suite should check every: function, branch and line of code. To ensure this has been achieved we need to run a code coverage tool that will generate data to indicate how comprehensive our testing suites really are. - -1. Using an appropriate _code coverage tool_, generate a coverage report that includes both the unit and integration tests. -2. You will probably have one or more modules that are _untestable_ because they don't return data to test. You should tell the code coverage tool to **ignore** these (but make sure you don't ignore too many!). -2. Use the _code coverage report_ to identify where the gaps are in your test suite and write additional tests until you score 100%. - -### 2.4 The TAP Protocol - -Now modify the output of your tests to generate data that follows the _TAP Protocol_. Once you have achieved this, pipe this data into a number of different **reporters** to generate the tests report as a web page and json file. Are there any other reporters that could be useful? - -### 2.5 Software Complexity Analysis - -The final step is to generate a report into the relative complexity of different parts of your system using the appropriate software complexity analysis tool for your chosen language. - -1. Identify the parts that have a relatively high complexity and find ways to refactor your code to reduce these. -2. Keep a record of the complexity score and use this to identify where changes have increased the complexity of a module. This may indicate poor architecture or code. \ No newline at end of file diff --git a/06 Automated Testing.md b/06 Automated Testing.md new file mode 100644 index 0000000..3a656c5 --- /dev/null +++ b/06 Automated Testing.md @@ -0,0 +1,172 @@ + +# Automated Testing + +In this worksheet you will be concluding your first sprint and learning about how automated tests can improve the quality of your code. You should refer to the [lecture slides](https://goo.gl/VHD2SH). + +Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. + +You should refer to [this week's presentation](https://drive.google.com/open?id=1xy3MWh96JUdI8DiAtOUFznA0aEf4FBzp8zbIrPBtTdw). + +In this worksheet you will be critically reviewing the code your team have written and creating a suite of automated tests to ensure this is maintained to a high standard. Because these tests are directly checking your source code there are different tools for each language. + +To help you complete the labs, there are working examples for different languages in the `exercises/05_code_quality/` directory. + +## 1 Review Meeting + +You will be given a date for the review meeting, this will typically be a week after the start of the sprint. During this meeting you will be expected to do a local demo of the software you built during the sprint so make sure you are prepared. + +The product owner should produce a one page summary of the features to be demonstrated. Use the table below as a template: + +| Type | Description | Status | Demo | +| ------ | ----------- | ---------------- | :--: | +| Story | xxx | completed | Y | +| Story | xxx | incomplete (why) | N | +| Bugfix | xxx | completed | Y | + +Make sure this has been sent to the client the night before the review meeting and ensure there are paper-copies for everyone in the meeting. The Scrum Master should also ensure that there is an up to date User story map and Kanban board visible to everyone in the meeting. + +1. Introductions: everyone explains what they have been working on. Keep this brief! +2. **Explain Features:** The _Product Owner_ goes go through summary of stories and tasks completed based on the summary circulated before the meeting. +3. Demo new functionality: product owner demos features and gets feedback from the client. This is recorded by all members of the team and any bugs identified are immediately added to the Kanban board. +4. Discuss key events/issues: The Scrum Master now discusses and resolves issues: + 1. Bugs and issues added to the Kanban board +5. The team review and update the User Story Map based on client feedback + +## 2 Sprint Planning + +As a team: + +1. Identify who will be the **Scrum Master** and who will be the **Product Owner**, perhaps you can rotate the jobs to other members of the team? +2. Ideally with the client present, take the first user story from the top row of your user story map: + 1. The product owner describes it from the user's perspective + 2. Discusses how it can be implemented and work collaboratively on a whiteboard/flipchart to define it's UI until the client/product owner is satisfied/ + 3. Explain the success criteria (how will the team know they have completed the story implementation. +3. Once the client has left: + 1. Break the story into the component tasks and write these on sticky notes. + 2. Use planning poker to estimate how many hours each task will take. + - If the estimated time for a task is longer than 4 hours, consider splitting the task down. + 3. Add them to the left column of your Kanban board. + 4. Finally the _Scrum Master_: + 1. adds up the estimated durations for the tasks on the Kanban board and + 2. draws out a burndown chart: + 1. The X axis should show the days in the sprint. + 2. the Y axis should show the combined duration. + 3. draws a staight line from the top of the Y axis to the end of the X axis to indicate the optimal burn rate. + +### 2.1 The Kanban Board + +Any tasks left incompleted should be left on the board + +``` +╔═════════╦════════════════╦════════════════╦═════════════════╦════════════════╦════════════════╗ +║ Story ║ To Do ║ Planning ║ Write Tests ║ Implementation ║ Done ║ +╟─────────╫────────────────╫────────────────╫─────────────────╫────────────────╫────────────────╢ +║ A ║ ┌────────┐ ║ ║ ║ ║ ║ +║ ║ │ a │ ║ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ ║ +╟─────────╫────────────────╫────────────────╫─────────────────╫────────────────╫────────────────╢ +║ B ║ ║ ║ ║ ┌────────┐ ║ ║ +║ ║ ║ ║ ║ │ b │ ║ ║ +║ ║ ║ ║ ║ └────────┘ ║ ║ +╟─────────╫────────────────╫────────────────╫─────────────────╫────────────────╫────────────────╢ +║ C ║ ┌────────┐ ║ ║ ║ ║ ║ +║ ║ │ c │ ║ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ ║ +║ ║ ┌────────┐ ║ ║ ║ ║ ║ +║ ║ │ d │ ║ ║ ║ ║ ║ +║ ║ └────────┘ ║ ║ ║ ║ ║ +╚═════════╩════════════════╩════════════════╩═════════════════╩════════════════╩════════════════╝ + +In this example, user story A was completed but because there was a bug identified during the +product demonstration, it remains on the board and the bug (a) is added to the tasks. +User story B remains on the board because it was not completed in the previous sprint. +User story C has been added to the current sprint. +``` + +## 2 Retrospective + +Each week the development team should meet up (without the client) and ask each member of the team to identify: + +1. What they should continue to do (existing good practice) +2. What they should **start** doing (new good practice) +3. What they should **stop** doing (eliminiate bad practices) + +## 4 Unit Testing + +If you have never done unit testing you should take time to complete the [Testing Your Code](https://www.codecademy.com/courses/testing-your-code) exercises on [Codeacademy](https://www.codecademy.com). + +### 4.1 Modularising Your Code + +It is vital that you provide a comprehensive suite of tests for your existing code. but before you can write effective unit tests you need to ensure that your code is split into a number of independent units. Each module: + +1. Should not be dependent on any other module you have written (you can have dependencies to third-part modules). +2. Should contain code that shares a similar function. + +``` +╔═════╗ ╔═════╗ ╔═════╗ In this example the code in modules (A), (B) and (C) +║ A ║ ║ B ║ ║ C ║ is not dependent on any of the other modules and so +╚══╤══╝ ╚══╤══╝ ╚══╤══╝ we can write unit tests for them. + │ │ │ + │ │ │ Module (D) imports the other three modules and so + │ ┌──┴──┐ │ we can't include this module in our unit tests. + └───────────→─┤ D ├─←───────────┘ + └─────┘ +``` + +Take time to tidy up your code ready for the next step. How much of the code can you isolate in code modules and unit test? Ideally all your code (embedded, API and client(s)) needs to be modularised. + +### 4.2 Writing Unit Tests + +You should now create a separate test suite for each of these code modules. The test suites are written in the same language as the code you are testing. There are unit testing suites available for all mainstream languages, use the examples in the `exercises/05_code_quality/05_unit/` directory to get you started. Whatever language you are testing: + +1. All unit tests should be kept together in a directory (typically named `spec/`). +2. Each code module should have its own test file that includes the name of the module in the format `unit-xxxx.xx`. +3. Each function/method in each module/class needs several tests: + 1. using valid data + 2. using threshold data + 3. using invalid data +4. Make sure all the tests pass at 100% + +There are examples of unit tests for multiple languages in the `/exercises/07_unit/` directory on GitHub. + +#### 4.2.1 Unit Testing Microcontroller Code + +One special case is writing and executing unit test on code that will eventually run on a microcontroller. There are two approaches that you should investigate and reflect on in your report: + +1. Arduino _libraries_ are written in standard C++ so, if there are no dependencies on Arduino-specific libraries you can write your unit tests using a standard testing framework. There is more information in the `exercises/05_code_quality/05_unit/cpp/` directory. +2. If you are using _Arduino-specific libaries_ you may need to test your code using an **Atmel emulator**. Again, there is more information in the same directory. + +## 5 Integration Testing + +Although you now have a suite of unit tests for the isolated mode modules/classes, there are some code modules/units/files that are not currently being tested. This could be for one of two reasons: + +1. They import other modules/classes. +2. They don't contains methods/functions that are _testable_ in that they don't return data (perhaps they send information to the web browser directly or return API data). + +it is quite possible to write tests for case (1) but, rather than testing the isolated module they are testing whether the module integrates with the rest of the modules (rather like testing the plumbing). We call these **integration tests** and they are written using the same tools as unit tests even though they serve a different purpose. + +``` +┌─────┐ ┌─────┐ ┌─────┐ In this example the code in modules (A), (B) and (C) +│ A │ │ B │ │ C │ has already been tested using our *unit tests*. +└──┬──┘ └──┬──┘ └──┬──┘ + │ │ │ Since all the isolated business logic is in these + │ │ │ modules, the purpose of module (D) is to import + │ ╔══╧══╗ │ and integrate the functions/methods in the other + └───────────→─╢ D ╟─←───────────┘ 3 modules. We therefore write integration tests + ╚═════╝ for module (D). +``` + +1. Create a testing suite for your integration module(s). These need to be saved in the same directory as your unit tests but add a different prefix, eg: `integration-xxxx.xx`. +2. Write a comprehensive suite of tests to make sure the functions from the other modules are working correctly together. + +## 6 Code Coverage + +In the previous two sections you were told to write a _comprehensive suite of tests_, but what is _comprehensive_? Our test suite should check every: function, branch and line of code. To ensure this has been achieved we need to run a code coverage tool that will generate data to indicate how comprehensive our testing suites really are. + +1. Using an appropriate _code coverage tool_, generate a coverage report that includes both the unit and integration tests. +2. You will probably have one or more modules that are _untestable_ because they don't return data to test. You should tell the code coverage tool to **ignore** these (but make sure you don't ignore too many!). +3. Use the _code coverage report_ to identify where the gaps are in your test suite and write additional tests until you score 100%. + +## 7 The TAP Protocol + +Now modify the output of your tests to generate data that follows the _TAP Protocol_. Once you have achieved this, pipe this data into a number of different **reporters** to generate the tests report as a web page and json file. Are there any other reporters that could be useful? diff --git a/06 Test-Driven Development.md b/06 Test-Driven Development.md deleted file mode 100644 index c82902a..0000000 --- a/06 Test-Driven Development.md +++ /dev/null @@ -1,170 +0,0 @@ - -# Test-Driven Development - -Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. - -You should refer to [this week's presentation](https://drive.google.com/open?id=1mqtXeAPd0uhShlDuvd4G25thJHE-AdHOEB-qwf-anB8). - -In your first sprint we focussed on the **Scrum Metholology**. In this second sprint we will continue using _Scrum_ but will now integrate the skills, tools and techniques we learned last week into a concept called **Test-Driven Development** (TDD). - -For this to work you need a modularised code base for each aspect of your product with all code covered by comprehensive unit and integration tests with 100% coverage. If this is not the case, go back to last week's lab worksheet and complete these exercises. - -## 1 Configuring Pull Requests - -In your first sprint you all had full access to the _Master Branch_ meaning anyone in the team could commit to it and merge branches into it. As you quickly discovered this caused a lot of problems. In this sprint your team will be making the master branch into a **protected branch**, restricting who can interact with it and how. - -### 1.1 Permissions - -The first step is to make sure that everyone in the team has been assigned the correct permission levels. - -1. One person in each _sub-team_ (eg, API, iOS, etc.) should be the designated **Code Owner**. -2. There are four permission levels: Guest, Developer, Reporter, Master. Everyone in the team should have developer permission. -3. The designated **Code Owner** for each repository should be given **Master** permissions. - -### 1.2 Protected Branches - -1. In your GitLab repositories go to `Settings > Repository` and expand the **Protected Branches** section. -2. In the **Branch** dropdown list choose `master`. -3. In the **Allowed to merge** dropdown list choose 'Masters', this will prevent except _code owners) from merging any code into this branch. -4. In the **Allowed to push** dropdown list make sure that you choose `No one`, we don't want any code to be pushed directly into this branch. - -## 2 Sprint Planning - -As a team: - -1. Choose a person in your team to act as the **Scrum Master** and as the **Product Owner**. -2. With the client present, discuss the remaining stories on the user story map: - 1. Remove any stories that are no longer relevent. - 2. Add user stories to reflect any additional functionality identified by the client. -3. re-prioritise the user stories by moving them up or down the user story map. -4. Identify what can be achieved in the next sprint and draw a horizontal line across the user story map to clearly identify this. -5. Take each of these user stories and, with the client present: - 1. The product owner describes it from the user's perspective - 2. The team and client discuss how it can be implemented and work collaboratively on a whiteboard/flipchart to define it's UI until the client/product owner is satisfied/ -6. Once the client has left: - 1. Break the story into the component tasks and write these on sticky notes. - 2. Use planning poker to estimate how many hours each task will take (split any tasks that you estimate will take more than 4 hours). - 3. Create a new Kanban board with 5 columns: to do, write tests, implementation, refactoring, done. - 4. Move any tasks you didn't complete in the first sprint onto this new board. - 5. Add the new tasks for this sprint to the left column of your new Kanban board. - 6. Draw up a fresh burndown chart for the current sprint. -``` -╔════════════════╦════════════════╦════════════════╦════════════════╦════════════════╗ -║ To Do ║ Write Tests ║ Implementation ║ Refactoring ║ Done ║ -╟────────────────╫────────────────╫────────────────╫────────────────╫────────────────╢ -║ ┌────────┐ ║ ║ ┌────────┐ ║ ║ ║ -║ │ │ ║ ║ │ │ ║ ║ ║ -║ └────────┘ ║ ║ └────────┘ ║ ║ ║ -║ ┌────────┐ ║ ║ ║ ║ ║ -║ │ │ ║ ║ ║ ║ ║ -║ └────────┘ ║ ║ ║ ║ ║ -║ ┌────────┐ ║ ║ ║ ║ ║ -║ │ │ ║ ║ ║ ║ ║ -║ └────────┘ ║ ║ ║ ║ ║ -╚════════════════╩════════════════╩════════════════╩════════════════╩════════════════╝ -In the example above note that one of the tasks from the previous sprint had been -started but was not completed. It has remained in the implementation stage. - -The new tasks for the current sprint have been added into the first column. -``` - -## 3 Conducting the Sprint - -In this second sprint you will be adopting some additional agile concepts: - -1. Feature branches (each task on the Kanban board should be developed in its own branch). -2. Implement **Test-Driven Development**: - 1. Write a _test list_ to define the functionality. - 2. Convert these into unit tests. - 3. Write code to pass the tests. - 4. Refactor the code, ensuring all tests still pass. -3. Pair programming (during the sprint, each member of the team should spend at least 2 days working with another member of the team using the _pair programming_ technique). -4. Implement pull requests to merge the feature into the master branch: - 1. When a task has been completed (and the entire test suite passes) the developer should create a **pull request** (see below). - 2. The _pull request_ will need to be reviewed by the **Code Owner** who will need to merge the code into the **Master Branch**. - -These extra skills will initially _slow your development process down_ as you get to grips with them however eventually you will see improvements both in the _velocity of development_ and in the _overall quality of the code_ your team are producing. - -### 3.1 Creating a Pull/Merge Requests - -This should be carried out only if the feature is complete and all the automated tests (functional and non-functional) pass. - -1. Click on the **Merge Requests** tab. -2. Click on the **New merge request** button. -3. The _source branch_ is the feature branch and the _target branch_ should be the master branch. -4. Click on the **Compare branches and continue** button. -5. Review the changes at the bottom of the next screen. -6. Add a title and description to the merge request, this should explain the work that has been done. -7. Click on **Submit merge request** - -### 3.2 Approving a Pull/Merge Request - -All requests will need to be reviewed by the **Code Owner**. - -1. The number of merge requests needing approval are shown on the **Merge Requests** tab. -2. Review the changes: - 1. Pull the branch. - 2. Review the changes (and run tests). -3. Check the **Remove source branch** box. -4. Click on the **Merge** button. - -If the code is not ready for merging you should add a comment and send it back to the development team. If the code is far from ready you can **close** the merge request. - -### 3.1 Daily Standup Meeting - -Your development team will still need to carry out a **Daily Standup meeting** every morning. Before this meeting, the _Scrum Master_ should: - -1. Check the _Kanban board_ is up to date. -1. add up the hours for all the tasks remaining incomplete on the Kanban board and using this to update the _Burndown Chart_. - -The Scrum Master needs to make sure everyone is engaged in the process. Adopt the following policy: - -1. Everyone should be there at the agreed time. Anyone delayed must phone the Scrum Master and the meeting postponed until they are there. -2. Everyone should be standing around the information radiators (whiteboard/flipchart). -3. Phones stay in pockets. meeting paused if anyone uses a phone (they are not focussed). -4. Laptops only to be used to demonstrate functionality. - -During the meeting: - -1. The Scrum Master reviews the burndown chart and tells the team whether they are ahead or behind schedule: -2. Now each member: - 1. explains what they have achieved since the last daily standup meeting, running the **acceptance test suite** and **unit test suite** to demonstrate this. - 2. uses the Kanban board to identify the tasks they will work on until the next meeting (tomorrow), flags with the team responsible and moves these forward on the board. - 3. Describes any technical challenges that are holding back development work. - -If any problems were identified during the standup these will need to be resolved by the appropriate team immediately **after** the daily standup. Make sure the resolution is explained to the _Scrum Master_ before continuing work. - -Now each team have tasks assigned and will need to implement these before the next daily standup. - -### 3.2 Development Process - -Once the tasks have been agreed the teams should immediately start working on them. The process is much more structured than the one used in the previous sprint. Make sure you follow each step carefully: - -1. A local feature branch is created if the task is new. This should be given a logical name such as `feature-xxx`. -2. This new branch should be _pushed_ to the remote so it can be seen by the rest of the team. -3. Everyone working on the feature should pull the branch and switch to it. -4. A set of **unit tests** and **integration tests** should be written to define the new functionality. -5. Now code should be written to pass the tests making sure all the **non-functional tests** such as the _linter_ and _code duplication checker_ still pass. -6. Once the unit and integration tests pass and the code in the branch adheres to the defined non-functional tests, it will need to be tidied up (refactored). Keep running the tests to make sure the refactoring doesn't break the code. -7. Now the branch can be merged into the master branch: - 1. Switch to the master branch. - 2. Merge the feature branch into the master branch. - 3. Delete the feature branch. - -## 4 Review Meeting - -You will be given a date for the review meeting, this will typically be a week after the start of the sprint. During this meeting you will be expected to do a local demo of the software you built during the sprint so make sure you are prepared. - -1. The **Product Owner** reads the user story/storys completed during the sprint. -2. The **Scrum Master** demonstrates the new features to the client. -3. Any bugs identified are added to the Kanban board to be addressed in the next sprint. - -The team then move on to the next _sprint planning meeting_ whilst the client is present. - -## 5 Retrospective - -Each week the development team should meet up (without the client) and ask each member of the team to identify: - -1. What they should continue to do (existing good practice) -2. What they should **start** doing (new good practice) -2. What they should **stop** doing (eliminiate bad practices) diff --git a/07 Advanced Version Control.md b/07 Advanced Version Control.md deleted file mode 100644 index 6dbce23..0000000 --- a/07 Advanced Version Control.md +++ /dev/null @@ -1,153 +0,0 @@ -# Advanced Version Control - -Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. - -You should refer to [this week's presentation](https://drive.google.com/open?id=1JmtlJWZy5Y5pFhDoggkLzaCSrbSa3plBh105nZtU2qA). - -In this worksheet you will be learning about some of the more powerful features of the Git version control system as well as the additional functionality offered by Git remote hosting sites such as **GitHub** and **GitLab**. - -## 1 Ignoring Files - -There are certain files and types of files that should not be included in a repository: - -1. Binary files -2. Third-party modules and libraries -3. Editor setting files -4. Local settings - -Git can be configured to ignore these through a file called `.gitignore` which should be added to the root folder in the repository (the one that contains the `.git/` directory). Here is an example of the contents of this file: - -``` -*.exe -node_modules/ -.DS_Store -``` - -Take a look at the repository you have been using and create a `.gitignore` file to handle the files you want excluding. - -But what happens if you have already committed a file that should be ignored? Git has a way to untrack files. - -```shell -$ git rm -r --cached filename -``` - -You will need to run this command for all files and directories you want to remove from the cache. The `-r` flag allows you to _recurse_ through subdirectories. - -## 2 Hooks - -The value generated by your team lies in the quality code they produce so you should take time to ensure this is securely stored on your remote repository (GitHub). The first step is to ensure each person in the team only has the minimum permissions needed to do their job. You have already added some security by configuring _protected branches_ in the last lab. We will now improve this. - -In the **Code Quality** worksheet you created a range of automated tests to check both _functional_ and _non-functional_ requirements. Many of these, such as the _linter_ returned a `0` on success and a non-zero if the test failed. Until now we have triggered these tests manually but, using **git hooks** these can be triggered in response to specific events. - -### 2.1 Pre-Commit - -Let's use a **Git Hook** to run checks on our code before allowing us to commit. In this example git will reject any code that fails the linting test. - -Use the terminal to create a new file in the `.git/hooks/` directory called `pre-commit`. - -```shell -$ nano .git/hooks/pre-commit -``` - -You should now write a **shell script** to run the linter for your chosen language. You should already have a suitable script. Remember to include a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line to identify the _script executable_, typically on a *nix system this will be `#!/bin/sh` if the script is a _shell script_. - -Finally you need to set the script as executable. - -```shell -$ chmod +x .git/hooks/pre-commit -``` - -Lets see if this works: - -1. Introduce a linting error (warnings won't work). -2. Manually trigger the linter to check it is being picked up properly. -3. Try staging and committing, it should be rejected. -4. Fix the linting error. -5. Try staging and committing again, it should work this time. - -By setting up a number of tests in git hooks you can automatically monitor the code quality _before_ it is committed. The downside is that the more tests you include, the slower the commit process. - -### 2.2 Pre-Push - -Rather than having a lot of tests that run at the commit stage you can also have tests that are triggered before the code is pushed (the push is rejected if they fail). The trick is to decide which tests should be `pre-commit` and which should be `pre-push`. This should be agreed by the team and the hooks set up before work starts. - -Have a go at setting up a `pre-push` hook. You can choose whatever test or tests you want to include in this. - -## 3 Bisecting - -If there is a bug in a branch (master or feature) we need to be able to find out when it was introduced. To do this we will use the `git bisect` tool. Let's run a **git bisect session**. - -1. Locate a branch that contains bad code. -2. Start the session by typing `git bisect start`. -3. The current commit is bad so type `git bisect bad`. -4. Locate an earlier commit which you know is good and note its short hash. -5. Now flag this as a good commit with `git bisect good xxxxxxx` where `xxxxxxx` is the hash. -6. Git will now flag a commit somewhere between the good and bad. Check this version out. - 1. If the bug is no longer there type `git bisect good`. - 2. If the bug is still there type `git bisect bad`. -7. This process will be repeated until the commit is found that introduced the bug. - 1. Type `git bisect reset` to move the `HEAD` to the commit before the bug was introduced. - -## 4 Rebasing - -Rebasing allows you to unplug the base of your feature branch and replug it further down the commit tree. This allows you to integrate changes to the master branch in your feature branch in a clean way. - -Take a few moments to review the structure of your git repository. Open the commit graph in GitLab `Repository > Graph` or use the `git log` command to get a visual representation. - -```shell -$ git log --pretty=format:"[%cn] %h %s (%cr)" --graph -``` - -You can navigate forward a screen using <space>, back a screen using `w` and quit using `q`. - -You should identify any branches and either: - -- If the feature is complete _delete the branch_. -- If the feature is not complete, do a rebase to make sure the feature branch contains the latest code from `master`. Check out the feature branch and `git rebase master`. - -This should make your git history much easier to understand. By rebasing your feature branches they will become far easier to merge back in to the `master` branch once the feature is complete. - -## 5 Tagging Releases - -Next we will use tags to mark the code snapshots corresponding to the software releases. - -- Go through the code in your master branch and note the 7 character _commit hash_ of the first working version of your code. After creating a tag it needs to be pushed to the remote: - -```shell -$ git tag -a v0.1 -m 'Describe version 0.1 clearly, you can use multiple lines' -$ git push origin v0.1 -``` - -These can be seen on GitLab under the `Repository > Tags` section which gives you the opportunity to download the code at that point. - -Repeat the operation for subsequent working versions of your code (typically as you complete each user story). If the release contains the **Minimum Viable Product** (MVP) the version should increment to `v1.0`. - -## 6 Extension Topics - -Alternative branching strategies: - -- Git Flow -- Forking Workflow - -Tools to help you document your project. - -- WEB PAGES - - create code coverage report as a web page. -- MARKDOWN -- WIKI - -- ISSUE TRACKER - - GitHub PROJECT = Kanban board. - - MILESTONES - sprints. - - using issue numbers in branches (start with number?) -- BRANCHING STRATEGIES -- WEBHOOKS - -## References - -[rebase explained](https://medium.freecodecamp.org/git-rebase-and-the-golden-rule-explained-70715eccc372) - - -[continuous integration workflows for feature branching](https://www.atlassian.com/continuous-delivery/continuous-integration-workflows-for-feature-branching) - -[git rebase](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase) \ No newline at end of file diff --git a/07 Test-Driven Development [2].md b/07 Test-Driven Development [2].md new file mode 100644 index 0000000..43abf54 --- /dev/null +++ b/07 Test-Driven Development [2].md @@ -0,0 +1,100 @@ + +# Test-Driven Development + +Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. + +You should refer to [this week's presentation](https://drive.google.com/open?id=1mqtXeAPd0uhShlDuvd4G25thJHE-AdHOEB-qwf-anB8). + +In your first sprint we focussed on the **Scrum Metholology**. In this second sprint we will continue using _Scrum_ but will now integrate the skills, tools and techniques we learned last week into a concept called **Test-Driven Development** (TDD). + +For this to work you need a modularised code base for each aspect of your product with all code covered by comprehensive unit and integration tests with 100% coverage. If this is not the case, go back to last week's lab worksheet and complete these exercises. + +## 1 Conducting the Sprint + +In this second sprint you will be adopting some additional agile concepts: + +1. Feature branches (each task on the Kanban board should be developed in its own branch). +2. Implement **Test-Driven Development**: + 1. Write a _test list_ to define the functionality. + 2. Convert these into unit tests. + 3. Write code to pass the tests. + 4. Refactor the code, ensuring all tests still pass. +3. Pair programming (during the sprint, each member of the team should spend at least 2 days working with another member of the team using the _pair programming_ technique). + +These extra skills will initially _slow your development process down_ as you get to grips with them however eventually you will see improvements both in the _velocity of development_ and in the _overall quality of the code_ your team are producing. To support this new workflow you will need to modify your Kanban board by adding some additional columns. These were explained in the lecture and you will be given detailed instruction in this worksheet. Make sure you replace any tasks on the new board. + +``` +╔═══════╦═══════════╦═══════════╦═══════════╦═══════════╦═══════════╦═══════════╦═══════════╗ +║ Story ║ To Do ║ Plan ║ Tests ║ Implement ║ Refactor ║ Regressn ║ Done ║ +╟───────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╢ +║ A ║ ┌───────┐ ║ ║ ║ ║ ║ ║ ║ +║ ║ │ a │ ║ ║ ║ ║ ║ ║ ║ +║ ║ └───────┘ ║ ║ ║ ║ ║ ║ ║ +╟───────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╢ +║ B ║ ║ ║ ║ ┌───────┐ ║ ║ ║ ║ +║ ║ ║ ║ ║ │ b │ ║ ║ ║ ║ +║ ║ ║ ║ ║ └───────┘ ║ ║ ║ ║ +╟───────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╫───────────╢ +║ C ║ ┌───────┐ ║ ║ ║ ║ ║ ║ ║ +║ ║ │ c │ ║ ║ ║ ║ ║ ║ ║ +║ ║ └───────┘ ║ ║ ║ ║ ║ ║ ║ +║ ║ ┌───────┐ ║ ║ ║ ║ ║ ║ ║ +║ ║ │ d │ ║ ║ ║ ║ ║ ║ ║ +║ ║ └───────┘ ║ ║ ║ ║ ║ ║ ║ +╚═══════╩═══════════╩═══════════╩═══════════╩═══════════╩═══════════╩═══════════╩═══════════╝ +``` + +## 3 Daily Standup Meeting + +Your development team will still need to carry out a **Daily Standup meeting** every morning. Before this meeting, the _Scrum Master_ should: + +1. Check the _Kanban board_ is up to date. +2. add up the hours for all the tasks remaining incomplete on the Kanban board and using this to update the _Burndown Chart_. + +The Scrum Master needs to make sure everyone is engaged in the process. Adopt the following policy: + +1. Everyone should be there at the agreed time. Anyone delayed must phone the Scrum Master and the meeting postponed until they are there. +2. Everyone should be standing around the information radiators (whiteboard/flipchart). +3. Phones stay in pockets. meeting paused if anyone uses a phone (they are not focussed). +4. Laptops only to be used to demonstrate functionality. + +During the meeting: + +1. The Scrum Master reviews the burndown chart and tells the team whether they are ahead or behind schedule: +2. Now each member: + 1. explains what they have achieved since the last daily standup meeting, running the **acceptance test suite** and **unit test suite** to demonstrate this. + 2. uses the Kanban board to identify the tasks they will work on until the next meeting (tomorrow), flags with the team responsible and moves these forward on the board. + 3. Describes any technical challenges that are holding back development work. + +If any problems were identified during the standup these will need to be resolved by the appropriate team immediately **after** the daily standup. Make sure the resolution is explained to the _Scrum Master_ before continuing work. + +Now each team have tasks assigned and will need to implement these before the next daily standup. + +### 3.1 Development Process + +Once the tasks have been agreed the teams should immediately start working on them. The process is much more structured than the one used in the previous sprint. Make sure you follow each step carefully. The task should be moved across the Kanban board according to the instructions. + +In this sprint you will be using a technique called **pair programming** whereby you will be developing the code in pairs with one person writing the code (the _driver_) and the other person checking it and making suggestions for improvement (the _navigator_). Switch the roles every 30 mins. + +1. The developer picks a task to work on from the **ToDo** column: + 1. They write their initials on the task and move it to the **Plan** column. +2. A local feature branch is created if the task is new. This should be given a logical name such as `feature-xxx`. + 1. This new branch should be _pushed_ to the remote so it can be seen by the rest of the team. + 2. Everyone working on the feature should pull the branch and switch to it. +3. The developer decides how it should be implemented, these plans should be shared with the rest of the team to get feedback. + 1. They now move the task to the **Tests** column. +4. A set of **unit tests** and **integration tests** should be written to define the new functionality. + 1. The tests should be run and seen to fail (we have not written the functionality yet). + 2. The task is now moved to the **Implement** column. +5. Now code should be written to pass the tests. + 1. Configure your development environment to automatically run the tests every time you modify a file and save. + 2. Once all the tests pass you should run your code coverage tool. If you don't get 100% coverage you will need to write additional tests. + 3. Once you have implemented the functionality and checked for 100% code coverage move the task to the **Refactor** column. +6. Once the unit and integration tests pass and you have 100% code coverage it will need to be tidied up (refactored). + 1. Study the code and identify ways it can be tidied up and made easier to understand. + 2. Keep running the tests to make sure the refactoring doesn't break the code. + 3. Once the code has been cleaned up and the tests still pass move the task to the **Regression** column. +7. Now the branch can be merged into the master branch: + 1. Switch to the master branch. + 2. Merge the feature branch into the master branch. + 3. Delete the feature branch. diff --git a/08 Non-Functional Testing.md b/08 Non-Functional Testing.md new file mode 100644 index 0000000..31f7154 --- /dev/null +++ b/08 Non-Functional Testing.md @@ -0,0 +1,116 @@ + +# Non-Functional Testing + +Lets start by adding a suite of tests to improve the general code quality. These won't test how well the code solves the user stories. Refer to the [lecture slides](https://drive.google.com/open?id=1TAyjgDdy-812mwhqrRCVT_MPNhvwApjsAJACmaSqSV8). + +## 1 Review Meeting + +You will be given a date for the review meeting, this will typically be a week after the start of the sprint. During this meeting you will be expected to do a local demo of the software you built during the sprint so make sure you are prepared. + +1. The **Product Owner** reads the user story/storys completed during the sprint. +2. The **Scrum Master** demonstrates the new features to the client. +3. Any bugs identified are added to the Kanban board to be addressed in the next sprint. + +## 2 Sprint Planning + +As a team: + +1. Identify who will be the **Scrum Master** and who will be the **Product Owner**, perhaps you can rotate the jobs to other members of the team? +2. Ideally with the client present, take the first user story from the top row of your user story map: + 1. The product owner describes it from the user's perspective + 2. Discusses how it can be implemented and work collaboratively on a whiteboard/flipchart to define it's UI until the client/product owner is satisfied/ + 3. Explain the success criteria (how will the team know they have completed the story implementation. +3. Once the client has left: + 1. Break the story into the component tasks and write these on sticky notes. + 2. Use planning poker to estimate how many hours each task will take. + - If the estimated time for a task is longer than 4 hours, consider splitting the task down. + 3. Add them to the left column of your Kanban board. + 4. Finally the _Scrum Master_: + 1. adds up the estimated durations for the tasks on the Kanban board and + 2. draws out a burndown chart: + 1. The X axis should show the days in the sprint. + 2. the Y axis should show the combined duration. + 3. draws a staight line from the top of the Y axis to the end of the X axis to indicate the optimal burn rate. + +## 3 Retrospective + +Each week the development team should meet up (without the client) and ask each member of the team to identify: + +1. What they should continue to do (existing good practice) +2. What they should **start** doing (new good practice) +3. What they should **stop** doing (eliminiate bad practices) + +## 4 Linting + +It can be tough for development teams to format their code in a consistent way: naming of variables and constants, extra whitespace, irregular indentation, and other “sloppiness” then often leads to actual bugs in the program. + +1. Install and run a suitable linter on the source code using its default settings. + - what errors and warnings does it flag up? + - are these easily fixable? +2. Can you find a plugin for your IDE so that the errors and warnings are flagged up in your editor? + - install the plugin and make sure it is highlighting the errors and warnings. +3. Most linters are configurable through a settings file. + 1. Create a simple settings file and make sure it is being read when the linter runs. + 2. Review the rules that can be customised and, in your team, decide on the agreed set of rules. + 3. Now use the linter output to ensure your code adheres to these rules. + +Whilst strictly not part of the _linting_ process, if you are using a _compiled language_ a good test is whether each source code file **compiles** correctly! + +## 5 Code Duplication + +The **Don't Repeat Yourself** (DRY) principle states that you should not have duplicate code scattered around your project as it makes it harder to find and fix bugs, but how can you check this? + +There are tools for all main programming languages that can flag up duplicate code across an entire project. + +1. Install a suitable tool that supports your language. +2. Run the tool using the default settings. + - does it flag up any code duplication? + - if so, can you locate this based on the information it provides? + - can this duplication be removed? +3. Most code duplication tools can be customised either through flags or a configuration file. + 1. Look at the documentation and identify how to customise the tool. + 2. Change some settings (for example the min lines) and run the tool. + - are the results more or less useful? + 3. As a team, decide on the settings you will be using and make sure they are used consistently for the remainder of the project. + +## 6 Checking Dependencies + +Every time you import a library/framework into your project it gets added to the codebase which means it takes longer to run the program and the size of the code increases. For this reason you should not be importing any dependency that you don't use. + +There are dependency checkers for most languages that can flag any imported module/library/framework which is not used in the code. + +1. Install a suitable tool that supports your language. +2. Run the tool and check any warnings/errors it generates. +3. Remove the unused modules/libraries/frameworks. +4. Run the tool again and repeat until no errors are reported. + +In some languages, all dependencies have to be recorded in a configuration file such as `package.json` in the case of NodeJS scripts. In these cases, by using different flags, the tool can: + +1. Identify any packages that are defined in config file and not used. +2. Identify any packages that are installed but not recorded in the config file. + +If you are using a language that uses a config file you should run these two additional tests. + +## 7 Profiling + +Software profiling is a dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. + +Profiling is normally used to improve program optimization and is achieved by instrumenting either the program source code or its binary executable using a tool called a **profiler**. + +Most mainstream languages include a profiler: + +1. Learn how the profiler works for your particular language, you may find some useful information in the `exercises/05_code_quality/04_profiling/` directory. +2. Activate the profiler. +3. Run your program. + - If appropriate, use a tool such as Apache Bench to simulate a load on your system. +4. This should have generated a **tick file**. + - use a suitable **tick interpreter** to analyse this data. + - Does it reveal any useful information about your program? +5. Can you use this data to improve your program? + +# 8 Software Complexity Analysis + +The final step is to generate a report into the relative complexity of different parts of your system using the appropriate software complexity analysis tool for your chosen language. + +1. Identify the parts that have a relatively high complexity and find ways to refactor your code to reduce these. +2. Keep a record of the complexity score and use this to identify where changes have increased the complexity of a module. This may indicate poor architecture or code. diff --git a/10 Continuous Delivery.md b/10 Continuous Delivery.md deleted file mode 100644 index 69c99b9..0000000 --- a/10 Continuous Delivery.md +++ /dev/null @@ -1,38 +0,0 @@ - -# Continuous Delivery (and Deployment) - -Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. - -You should refer to [this week's presentation](https://drive.google.com/open?id=1SY1VGNr4X9-gLq0OLeOPmVmH1E4CeaBxFKJUygLSd_c). - -Welcome to the final sprint where you will be applying all the skills and knowledge you have acquired over the previous sprints but also build a continuous delivery pipeline to completely automate the delivery process. - -## 1 Configure Systems - -For a complete continuous delivery pipeline you will need to configure two platforms. The first will be a test environment where you will run your _acceptance tests_ and demonstrate functionality to the client whilst the second will be your live system. The systems you develop will depend on the component you are developing: - -1. For the embedded system, the test environment could be a microcontroller where you can programmatically control the inputs and monitor the outputs. The live environment will be the sensor module package that will be deployed 'in the wild'. -2. For the API you will need two cloud-based servers. There are plenty of platforms such as [Google Cloud](https://cloud.google.com) and [AWS](https://aws.amazon.com) however you should also consider using [Heroku](https://heroku.com) who provide up to 5 free microservers (plus there are tutorials in the `exercises/03_architecture/deployment` directory and it is used in the sample project. -3. For the smartphone apps, the test environment can be an emulator but you should also consider a pipeline that pushes the app to test devices. Examples of this is the [TestFlight](https://developer.apple.com/testflight/) tool for iOS but there are plenty of cross-platform [alternatives](https://rollout.io/blog/testflight-alternatives-ios-beta-testing/) you can try. - -## 2 Configure the Pipeline - -Now you have the different environments configured we need implement a full Continuous Delivery pipeline that includes: - -1. Unit and integration tests. -2. Non-functional tests. -3. Deployment to a test environment to: - 1. Run acceptance tests. - 2. Demonstrate to the client. -4. Deployment to a live enviroment. - -1. In your team, agree on the stages you need in your pipeline and what jobs should go in each stage. You should draw a diagram to ensure the logic works. -2. Modify your GitLab CI pipeline by editing the `.gitlab-ci.yml` file. use the examples in this repository as well as the online examples. - -## 3 Final Sprint - -This is your fourth and final sprint in this module. In it you need to incorporate all the skills and knowledge from the previous sprints but you should also: - -1. Make use of Continuous Delivery. -2. Make use of an alternative Git workflow. -3. Try using alternative agile methodologies. diff --git a/08 Continuous Integration.md b/10 Continuous Integration [3].md similarity index 93% rename from 08 Continuous Integration.md rename to 10 Continuous Integration [3].md index 91f71b9..b7a2566 100644 --- a/08 Continuous Integration.md +++ b/10 Continuous Integration [3].md @@ -25,6 +25,13 @@ You will need to create a `.gitlab-ci.yml` file in the root directory of your pr You will also need to configure GitLab to only allow merging if all tests have passed. In this way you can bypass the requirement for the code to be reviewed by the Scrum Master which should speed up the process of integrating code into the Master branch. +### 1.1 Examples + +To help you configure your GitLab CI pipeline there are a couple of sample repositories you should be studying which cover most of the platforms you are developing for: + +1. [ci-arduino](https://gitlab.com/covcom/ci-arduino) shows how to build a CI pipeline using the [PlatformIO](https://platformio.org) tools. +2. [ci-nodejs](https://gitlab.com/covcom/continuous-integration-example) shows how to build a CI and CD pipeline for a NodeJS API. + ### 1.1 Continuous Integration and Arduino Code The challenge for carrying out unit and integration tests for Arduino code is that it has to run on a server rather than on a physical microcontroller. There are links to useful web resources in the `exercises/08_ci/arduino/` directory. diff --git a/README.md b/README.md index ed277d5..226f0d8 100644 --- a/README.md +++ b/README.md @@ -30,15 +30,16 @@ During this module you will be working in medium-sized multi-skilled development 1. Professional development 2. Agile planning (planning your agile project) -3. Architecture -4. Agile development (and your first sprint) +3. Sprint planning +4. Effective sprints (and your first sprint) 5. Automated code testing 6. Test-driven development (and the second sprint) -7. Advanced version control -8. Continuous integration (and the third sprint) +7. Non-functional testing +8. Advanced Git (and the third sprint) 9. Acceptance testing -10. Continuous delivery (and the final sprint) -11. Exam revision +10. Continuous integration (and the fourth sprint) +11. Automated deployment and exam revision +12. Continuous delivery (and the bonus sprint) ## The Team @@ -73,3 +74,10 @@ They would like to have a smartphone app to use the data in the following ways: - Map of the area with overlays showing pollution levels. - Summary of the pollution in the user's current location mapped against acceptable norms - alerts if pollution exceeds the agreed levels. + +## Git Tags + +``` +$ git tag -a 1718JANMAY 9b89d29 -m "1718JANMAY" +$ git push --tags origin master +``` diff --git a/exams/extras.md b/exams/extras.md index da053be..e56a64f 100644 --- a/exams/extras.md +++ b/exams/extras.md @@ -51,6 +51,12 @@ What is BDD? ---- +What is the "Iron Triangle of Planning" and what are the three limitations, explain each? + +Describe both waterfall and agile approaches with respect to these limitations. + +---- + List and explain four problems with detailed specifications. How does an agile methodology reduce risk? @@ -85,6 +91,14 @@ Explain the following terms used in agile development: ---- +What is "Docker"? + +Explain the purpose of the relationship between **Docker Engine**, **Docker Compose** and **Docker Machine**. + +WHat is the purpose and what are the benefits of **Docker Swarm**. + +---- + MoSCoW is an acronym often used in agile planning: 1. Expand the acronym and explain it @@ -200,4 +214,4 @@ Continuous Integration and Continuous Deployment are often used by software deve 2. What are the benefits 3. What are the challenges to adoption ----- \ No newline at end of file +---- diff --git a/exercises/04_agile_dev/01_sensor_module/kit_list.md b/exercises/04_agile_dev/01_sensor_module/kit_list.md deleted file mode 100644 index f83bc8f..0000000 --- a/exercises/04_agile_dev/01_sensor_module/kit_list.md +++ /dev/null @@ -1,40 +0,0 @@ - -# Kit List - -The following items are in the kit that has been issued to your team. Make sure you check everything is there before signing for it. The kit must be returned during week 10 of the module. - -| Equipment | Cost | -| --------------------------------- | ----: | -| NodeMCU ESP8266 CP2102 v3 | £6.99 | -| Short micro-USB cable | £3.99 | -| Breadboard | £1.56 | -| set of Jumper wires | £3.95 | -| Temperature sensor module DS18B20 | £1.35 | -| Temperature/Humidity module DHT11 | £1.46 | -| Gas sensor MQ-135 | £5.60 | -| Light sensor GY-2561 TSL2561 | £1.62 | -| Vibration sensor SW-420 | £1.76 | -| Sound sensor KY-038 | £3.60 | -| Stanley storage box | £7.30 | - -**NOTE:** One member of the team will have to sign for the kit at the start of the project. Any missing items will be charged at the prices in the table above. - -Please complete the following and return to the lab supervisor. - -  - -Team: _______________________ - -  - -  - -Signature: _________________________________ - -  - -Name: _____________________________ - -  - -Date: ____________________ diff --git a/exercises/05_code_quality/05_unit/cpp/README.md b/exercises/05_code_quality/05_unit/cpp/README.md deleted file mode 100644 index 9c9d53b..0000000 --- a/exercises/05_code_quality/05_unit/cpp/README.md +++ /dev/null @@ -1,24 +0,0 @@ - -## Unit Testing C++ Code - -In this tutorial we will be using the [Google Test](https://github.com/google/googletest) unit testing framework. - -## Installation - -Rather than provide instructions for different platforms there are already detailed instruction for [Linux](https://stackoverflow.com/questions/13513905/how-to-setup-googletest-as-a-shared-library-on-linux). [MacOS](https://github.com/iat-cener/tonatiuh/wiki/Installing-Google-Test-For-Mac) and [Windows](https://github.com/iat-cener/tonatiuh/wiki/Installing-Google-Test-For-Windows). - -## Getting Started - -Here is a [really good tutorial](https://www.ibm.com/developerworks/aix/library/au-googletestingframework.html) from IBM showing you how to write your first unit test suite. - -## Unit Testing Arduino Code - -https://stackoverflow.com/questions/780819/how-can-i-unit-test-arduino-code - -https://github.com/mmurdoch/arduinounit/ - -### Arduino Emulators - -https://github.com/maniacbug/ncore - -https://github.com/buserror/simavr diff --git a/resources/.images/ESP8266.png b/resources/.images/ESP8266.png new file mode 100644 index 0000000..ca795fd Binary files /dev/null and b/resources/.images/ESP8266.png differ diff --git a/resources/.images/PlatformIO_logo.png b/resources/.images/PlatformIO_logo.png new file mode 100644 index 0000000..353b215 Binary files /dev/null and b/resources/.images/PlatformIO_logo.png differ diff --git a/resources/.images/arduino-micro-usb-microcontroller-2_1.png b/resources/.images/arduino-micro-usb-microcontroller-2_1.png new file mode 100644 index 0000000..d2ceb9b Binary files /dev/null and b/resources/.images/arduino-micro-usb-microcontroller-2_1.png differ diff --git a/exercises/.images/code_coverage_lines.png b/resources/.images/code_coverage_lines.png similarity index 100% rename from exercises/.images/code_coverage_lines.png rename to resources/.images/code_coverage_lines.png diff --git a/exercises/.images/code_coverage_summary.png b/resources/.images/code_coverage_summary.png similarity index 100% rename from exercises/.images/code_coverage_summary.png rename to resources/.images/code_coverage_summary.png diff --git a/exercises/.images/github_pull_request_creating.png b/resources/.images/github_pull_request_creating.png similarity index 100% rename from exercises/.images/github_pull_request_creating.png rename to resources/.images/github_pull_request_creating.png diff --git a/exercises/.images/github_pull_request_editing.png b/resources/.images/github_pull_request_editing.png similarity index 100% rename from exercises/.images/github_pull_request_editing.png rename to resources/.images/github_pull_request_editing.png diff --git a/exercises/.images/github_pull_request_review.png b/resources/.images/github_pull_request_review.png similarity index 100% rename from exercises/.images/github_pull_request_review.png rename to resources/.images/github_pull_request_review.png diff --git a/exercises/.images/nodemcu.png b/resources/.images/nodemcu.png similarity index 100% rename from exercises/.images/nodemcu.png rename to resources/.images/nodemcu.png diff --git a/resources/.images/platformio_toolbar.png b/resources/.images/platformio_toolbar.png new file mode 100644 index 0000000..fe6810b Binary files /dev/null and b/resources/.images/platformio_toolbar.png differ diff --git a/resources/.images/platformio_wizard.png b/resources/.images/platformio_wizard.png new file mode 100644 index 0000000..532a2a7 Binary files /dev/null and b/resources/.images/platformio_wizard.png differ diff --git a/exercises/.images/pre-commit-hook.jpeg b/resources/.images/pre-commit-hook.jpeg similarity index 100% rename from exercises/.images/pre-commit-hook.jpeg rename to resources/.images/pre-commit-hook.jpeg diff --git a/exercises/.images/submodules.png b/resources/.images/submodules.png similarity index 100% rename from exercises/.images/submodules.png rename to resources/.images/submodules.png diff --git a/exercises/.images/user_story_map.png b/resources/.images/user_story_map.png similarity index 100% rename from exercises/.images/user_story_map.png rename to resources/.images/user_story_map.png diff --git a/exercises/04_agile_dev/01_sensor_module/ESP8266_arduino.md b/resources/01_prof_dev/ESP8266_arduino.md similarity index 50% rename from exercises/04_agile_dev/01_sensor_module/ESP8266_arduino.md rename to resources/01_prof_dev/ESP8266_arduino.md index 50a6127..aabfc95 100644 --- a/exercises/04_agile_dev/01_sensor_module/ESP8266_arduino.md +++ b/resources/01_prof_dev/ESP8266_arduino.md @@ -1,10 +1,20 @@ # Configuring ESP8266 Development Using the Arduino IDE +Although the IoT kit comes complete with an [ESP8266 development board](https://www.losant.com/blog/top-6-esp8266-modules) which can be programmed in C++ using the [Arduino IDE](https://www.arduino.cc/en/Main/Software) or with [MicroPython](https://docs.micropython.org/en/latest/esp8266/esp8266/tutorial/intro.html), you should only use it if you are already familiar with either of these development environments. If not you are advised to use whatever microcontroller and tool chain you are most comfortable with. + +The rest of this worksheet covers setting up the Arduino IDE to be able to use it to create scripts and flash them. + You will need to install drivers on your computer. Look on the base of the NodeCMU. If it states you need the **2102 driver** you can download and install [here](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers). Install the Arduino IDE +Install the [CH340 Drivers](https://sparks.gogo.co.nz/ch340.html) for your chosen platform. + +You may need to install the [NodeMCU Drivers](https://github.com/nodemcu/nodemcu-devkit/tree/master/Drivers) for your chosen platform. + +Here are the [Official FTDI Drivers](http://www.ftdichip.com/Drivers/VCP.htm) for the different operating systems. + Arduino > Preferences Paste the following into the **Additional Boards Manager** box. @@ -15,23 +25,43 @@ Click on OK to close the Preferences window Tools > Boards > Board manager. -find `esp8266 by esp8266 community` and install. +find `esp8266 by esp8266 community` and install the latest version (2.4.0 at the time of writing). ## Board setup for programming After installing the drivers, you can choose the correct board in your IDE. -In Arduino IDE --> Tools --> Board --> Generic ESP8266 Module +In Arduino IDE --> Tools --> Board --> NodeMCU 1.0 (ESP 12E Module) + +If the option is available, modify the reset method in Arduino IDE to "nodemcu" by selecting `Tools -> Reset Method -> nodemcu`. + +If the sketch doesn't upload correctly you may need to change the board type to `Generic ESP8266 Module`. + +NOTE Next you need to set the COM port and baud rate. +To find out the COM port that the arduino is plugged into, you can unplug the arduino, check the port which are active via Tools --> Port in Arduino IDE. Then plug the board in again and you should see an additional COM port listed and select it. + +On a Mac the port looks like `/dev/cu-wchusbserial1460`. + To find out which COM port you have connected your NodeMCU development board to, you can use Device Manager or a Serial Watcher [Apps Anywhere](https://appsanywhere.coventry.ac.uk/) program. For programming you will need to select the COM port and Baud Rate 115200 Upload Speed. +## Useful Libraries + +You will need to install a number of libraries to add more functionality to your Arduino projects. These need to be unzipped and placed in a `libraries/` directory inside the save directory. There are many libraries to use but you might find the following useful: + +1. The [ESP8266/Arduino](https://github.com/esp8266/Arduino/releases) library was installed when you added the json link to the boards manager. It includes the [ESP8266WiFi](https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/readme.html) library to connect to WiFi access points using an SSID and password. +2. The [imroy/PuSubClient](https://github.com/Imroy/pubsubclient) library makes it simple to connect and publish to an MQTT broker (server) from an ESP8266. +3. Adafruit have created their own [Adafruit_MQTT_Library](https://github.com/adafruit/Adafruit_MQTT_Library) which makes it easy to connect to and publish data to their cloud server. +4. The [ArduinoUnit](https://github.com/mmurdoch/arduinounit/releases) library allows you to write and run unit and integration tests. + ## Connecting to WiFi One of the most important jobs is to make sure the NodeMCU can connect to a WiFI network, otherwise you won't be able to send any data to the API. There is a useful library called `ESP8266WiFi` which was installed if you followed the steps above. Below is a simple sketch to test the connection to the WiFi network. + ```cpp #include #include @@ -43,7 +73,7 @@ void setup() { delay(10); // We start by connecting to a WiFi network - WiFiMulti.addAP("ssid", "password"); + WiFiMulti.addAP("ECL-LEGO-ROBOTS", "9cjjp64270"); Serial.println(); Serial.println(); diff --git a/resources/01_prof_dev/IoT IDE Configuration.md b/resources/01_prof_dev/IoT IDE Configuration.md new file mode 100644 index 0000000..001e3bd --- /dev/null +++ b/resources/01_prof_dev/IoT IDE Configuration.md @@ -0,0 +1,160 @@ + +# Configuring The IoT Editor + +Install [Visual Studio Code](https://code.visualstudio.com) and then install the [PlatformIO](https://platformio.org) plugin. This can take some time! + +Once installed you will need to restart VS Code. After restarting you will see the **PlatformIO Home** icon in the blue **Status Bar**. If the bar is not visible you can fix this using the _View > Show Status Bar_ menu. Clicking on this brings up the **PIO Home** screen and displays the **PlatformIO Toolbar** at the bottom of the IDE. This contains a number of important buttons: + +![PlatformIO Toolbar](../.images/platformio_toolbar.png) + +1. Home +2. Build +3. Upload +4. Upload to remote device +5. Clean +6. Test +7. Run task +8. Serial monitor +9. New terminal + +## 1 Creating a PlatformIO Account + +In order to complete this tutorial you will need to log in with a [**PlatformIO** account](https://community.platformio.org). Yu will be sent an activation email. + +Locate the **New Project** button on the **PIO Home** screen and click it to launch the wizard. + +![The PlatformIO Wizard](../.images/platformio_wizard.png) + +You should give your project a title (Blink). For the board use the dropdown list to select the **NodeMCU 1.0 (ESP-12E Module)** and make sure the **Arduino** framework is selected. There is a default location for the project files but if you uncheck the **Location** checkbox you can choose where to save the project. + +If you open the explorer tab in VSCode (the first icon down the left of the editor) you can see that PlatformIO has created a series of directories and files: + +``` +project_dir +├── lib +│ └── readme.txt +├── platformio.ini +└── src + └── main.cpp +``` + +The project files should be saved in the `src/` directory and any project-specific libraries need to be in separate directories in the `lib/` directory. + +Open the `src/main.cpp` file and replace its contents with the following: + +``cpp +#include "Arduino.h" + +#define LED_BUILTIN 2 + +void setup() { + // initialize LED digital pin as an output. + pinMode(LED_BUILTIN, OUTPUT); +} + +void loop() { + digitalWrite(LED_BUILTIN, HIGH); + delay(1000); + digitalWrite(LED_BUILTIN, LOW); + delay(1000); +} +`` + +Plug in your ESP8266, click on the **Build** button. Once the code is compiled and linked click on the **Upload** button to upload the hex file to the microcontroller. This should result in the onboard LED flashing on and off. + +## 2 Unit Testing + +Note that this feature requires a [paid account](https://platformio.org/pricing). The cheapest option is the **Basic Non-Commercial** licence. Your first month is free. + +Now we will write some unit tests for our program. Start by creating a new directory called `test/` and create a file in it called `test_main.cpp`. Your project directories and files should look soemthing like the following: + +``` +project_dir +├── lib +│ └── readme.txt +├── platformio.ini +├── src +│ └── main.cpp +└── test + └── test_main.cpp +``` + +Edit the `main.cpp` file and add the two lines as shown. + +```cpp + +#include "Arduino.h" + +#ifndef UNIT_TEST // IMPORTANT LINE! + +#define LED_BUILTIN 2 + +void setup() { + // initialize LED digital pin as an output. + pinMode(LED_BUILTIN, OUTPUT); +} + +void loop() { + digitalWrite(LED_BUILTIN, HIGH); + delay(1000); + digitalWrite(LED_BUILTIN, LOW); + delay(1000); +} + +#endif // IMPORTANT LINE! +``` + +Now add the following code to the new test file. + +```cpp +#include +#include + +#ifdef UNIT_TEST + +void test_led_builtin_pin_number(void) { + TEST_ASSERT_EQUAL(LED_BUILTIN, 2); +} + +void test_led_state_high(void) { + digitalWrite(LED_BUILTIN, HIGH); + TEST_ASSERT_EQUAL(digitalRead(LED_BUILTIN), HIGH); +} + +void test_led_state_low(void) { + digitalWrite(LED_BUILTIN, LOW); + TEST_ASSERT_EQUAL(digitalRead(LED_BUILTIN), LOW); +} + +void setup() { + // NOTE!!! Wait for >2 secs + // if board doesn't support software reset via Serial.DTR/RTS + delay(2000); + + UNITY_BEGIN(); // IMPORTANT LINE! + RUN_TEST(test_led_builtin_pin_number); + + pinMode(LED_BUILTIN, OUTPUT); +} + +uint8_t i = 0; +uint8_t max_blinks = 5; + +void loop() { + if (i < max_blinks) + { + RUN_TEST(test_led_state_high); + delay(500); + RUN_TEST(test_led_state_low); + delay(500); + i++; + } + else if (i == max_blinks) { + UNITY_END(); // stop unit testing + } +} + +#endif +``` + +To run the tests click on the **Test** button, you will need to log in with your PlatforIO account. \ No newline at end of file diff --git a/exercises/01_prof_dev/README.md b/resources/01_prof_dev/README.md similarity index 100% rename from exercises/01_prof_dev/README.md rename to resources/01_prof_dev/README.md diff --git a/resources/01_prof_dev/heroku.md b/resources/01_prof_dev/heroku.md new file mode 100644 index 0000000..ff33530 --- /dev/null +++ b/resources/01_prof_dev/heroku.md @@ -0,0 +1,104 @@ + +# Deploying a NodeJS App to Heroku + +In this worksheet you will learn how to host a NodeJS script on the free Heroku hosting platform. + +When you create your Restify/Express routes file you need to ensure that you read the `PORT` environment variable and use this value to determine what port to run the server on. Here is a simple example to illustrate this point using the `http` package. + +```javascript +const http = require('http') +const server = http.createServer( (req, res) => { + res.writeHead(200) + res.end('hello world') +}).listen(process.env.PORT || 8080) +``` + +Heroku needs a valid config file so we can use the npm init command to run through the config wizard. Complete this and then open the package.json file it creates. It should look like this. + +```json +{ + "name": "AppNameHere", + "version": "1.0.0", + "description": "your description here", + "main": "index.js", + "scripts": { + "test": "echo \"Error: no test specified\" && exit 1", + "start": "node index.js" + } +} +``` + +The important keys are `main` and `scripts.start` as Heroku will use these to determine how to start your script. You should also make sure that all dependencies are included so it knows what needs to be installed. + +## Committing the Changes + +Finally make sure you have committed any changes to your project and that your working directory is clean. It is also recommended that you push changes to your remote repository. + +Create yourself an account on the Heroku website and open the [dashboard](https://dashboard.heroku.com/apps). + +## Install the Heroku CLI + +We will be interacting with Heroku using a command-line utility. Open up the Terminal window and install this. + +```shell +$ wget -O- https://toolbelt.heroku.com/install-ubuntu.sh | sh +``` + +Once installed you need to use this to log in which will exchange SSH keys. + +```shell +$ heroku login + Enter your Heroku credentials. + Email: johndoe@gmail.com + Password (typing will be hidden): + Authentication successful. +``` + +Next we need to create our remote app on the cloud. If you don't specify a name parameter one +will be automatically generated for you. + +```shell +$ heroku create myappname + Creating myappname... done, stack is cedar-14 + https://myappname.herokuapp.com/ | https://git.heroku.com/myappname.git + Git remote heroku added +``` + +If you check your git remotes you should find that heroku has added a second one. + +```shell +$ git remote -v + heroku https://git.heroku.com/myappname.git (fetch) + heroku https://git.heroku.com/myappname.git (push) + origin git@gitlab.com:xxx.git (fetch) + origin git@gitlab.com:xxx.git (push) +``` + +## Deploying to Heroku + +Assuming the git working directory is clean, deploying is as simple as pushing to the heroku remote instead of the origin remote. To push to the Heroku server: + +```shell +$ git push heroku master +``` + +This will push the latest commits to the Heroku server. Once this is completed, the server will be stopped and then restarted using the information contained in the config file. You should be able to view the progress by checking the messages appearing in the terminal window. + +## Running an Instance + +The first time the app gets deployed we need to start an app instance running. + +```shell +$ heroku ps:scale web=1 +``` + +You should now be able to view your application on the server. + +## Checking the Logs + +Heroku keeps a detailed log which can be viewed using the heroku logs command. By passing the tail flag we only see the last 10 lines. For example if you view the URL, the following gets added to the log file. + +```shell +$ heroku logs --tail + 2015-04-18T18:34:57.199901+00:00 heroku[router]: at=info method=GET path="/" host=myappname.herokuapp.com request_id=c98d5ee5-afb8-47fd-bf78-05c2ac3d3713 fwd="90.244.82.220" dyno=web.1 connect=2ms service=8ms status=200 bytes=124 +``` diff --git a/resources/01_prof_dev/kit_list.md b/resources/01_prof_dev/kit_list.md new file mode 100644 index 0000000..e361b53 --- /dev/null +++ b/resources/01_prof_dev/kit_list.md @@ -0,0 +1,51 @@ + +# Kit List + +The following items are in the kit that has been issued to your team. Make sure you check everything is there before signing for it. The kit must be returned during week 10 of the module. + +The following items will be in the kit issued to your team. Make sure you check everything is there before signing for it. + +| Equipment | Qty | Cost | +| ----------------------------------------------------------- | --: | ----: | +| [Storage box](http://amzn.eu/hyI4x9J) | 1 | £7.30 | +| [NodeMCU ESP8266 CP2102 v3](http://amzn.eu/iFhW1f4) | 1 | £6.99 | +| [Micro-USB cable 30cm](http://amzn.eu/eJ6z1Ux) | 1 | £3.99 | +| [Breadboard](http://amzn.eu/4r8UL9Q) | 2 | £1.56 | +| [Breadboard power supply](http://amzn.eu/3YVPeDC) | 1 | £2.48 | +| [AA Battery Holder to 9v](http://amzn.eu/616kZXO) | 1 | £1.99 | +| [Power Jack to 9v clip](http://amzn.eu/9HzCdCB) | 1 | £1.00 | +| [Jumper wires](http://amzn.eu/ejw4p3Q) | 65 | £3.95 | +| [Mixed resistors](http://amzn.eu/76cxzbo) | - | £1.00 | +| [Mult-coloured LED](http://amzn.eu/88DIvzz) | 6 | £1.00 | +| [RGB LED](http://amzn.eu/in4Ovho) | 4 | £1.00 | +| [Temperature sensor module DS18B20](http://amzn.eu/6h2mzBC) | 1 | £1.35 | +| [Temperature/Humidity module DHT11](http://amzn.eu/glrhIqs) | 1 | £1.46 | +| [Gas sensor MQ-135](http://amzn.eu/h573jLl) | 1 | £5.60 | +| [Light sensor GY-2561 TSL2561](http://amzn.eu/a07k83G) | 1 | £1.62 | +| [Vibration sensor SW-420](http://amzn.eu/crleUBd) | 1 | £1.76 | +| [Sound sensor KY-038](http://amzn.eu/3tkqZG2) | 1 | £3.60 | +| [Ultrasonic sensor HC-SR04](http://amzn.eu/cEqKyuC) | 1 | £1.00 | + +**NOTE:** One member of the team will have to sign for the kit at the start of the project. Any missing items will be charged at the prices in the table above. + +Please print this page, complete and and give to the lab supervisor when collecting your kit. + +You will be provided with a photo of the kit box contents, please ensure all items are placed in the correct places when returning the kit as it will make it easier to check for missing items. + +  + +Team: _______________________ + +  + +  + +Signature: _________________________________ + +  + +Name: _____________________________ + +  + +Date: ____________________ diff --git a/exercises/03_architecture/appInventor.md b/resources/03_architecture/appInventor.md similarity index 100% rename from exercises/03_architecture/appInventor.md rename to resources/03_architecture/appInventor.md diff --git a/exercises/03_architecture/deployment/README.md b/resources/03_architecture/deployment/README.md similarity index 100% rename from exercises/03_architecture/deployment/README.md rename to resources/03_architecture/deployment/README.md diff --git a/exercises/03_architecture/docker for mac/README.md b/resources/03_architecture/docker for mac/README.md similarity index 100% rename from exercises/03_architecture/docker for mac/README.md rename to resources/03_architecture/docker for mac/README.md diff --git a/exercises/03_architecture/docker for mac/api/Dockerfile b/resources/03_architecture/docker for mac/api/Dockerfile similarity index 100% rename from exercises/03_architecture/docker for mac/api/Dockerfile rename to resources/03_architecture/docker for mac/api/Dockerfile diff --git a/exercises/03_architecture/docker for mac/api/server.js b/resources/03_architecture/docker for mac/api/server.js similarity index 100% rename from exercises/03_architecture/docker for mac/api/server.js rename to resources/03_architecture/docker for mac/api/server.js diff --git a/exercises/03_architecture/docker for mac/website/index.html b/resources/03_architecture/docker for mac/website/index.html similarity index 100% rename from exercises/03_architecture/docker for mac/website/index.html rename to resources/03_architecture/docker for mac/website/index.html diff --git a/exercises/03_architecture/docker for mac/website/style.css b/resources/03_architecture/docker for mac/website/style.css similarity index 100% rename from exercises/03_architecture/docker for mac/website/style.css rename to resources/03_architecture/docker for mac/website/style.css diff --git a/exercises/03_architecture/docker/Dockerfile b/resources/03_architecture/docker/Dockerfile similarity index 100% rename from exercises/03_architecture/docker/Dockerfile rename to resources/03_architecture/docker/Dockerfile diff --git a/exercises/03_architecture/docker/README.md b/resources/03_architecture/docker/README.md similarity index 100% rename from exercises/03_architecture/docker/README.md rename to resources/03_architecture/docker/README.md diff --git a/exercises/03_architecture/docker/docker-compose.yml b/resources/03_architecture/docker/docker-compose.yml similarity index 100% rename from exercises/03_architecture/docker/docker-compose.yml rename to resources/03_architecture/docker/docker-compose.yml diff --git a/exercises/03_architecture/docker/server.js b/resources/03_architecture/docker/server.js similarity index 100% rename from exercises/03_architecture/docker/server.js rename to resources/03_architecture/docker/server.js diff --git a/exercises/03_architecture/kafka/java/Producer.java b/resources/03_architecture/kafka/java/Producer.java similarity index 100% rename from exercises/03_architecture/kafka/java/Producer.java rename to resources/03_architecture/kafka/java/Producer.java diff --git a/exercises/03_architecture/kafka/java/README.md b/resources/03_architecture/kafka/java/README.md similarity index 100% rename from exercises/03_architecture/kafka/java/README.md rename to resources/03_architecture/kafka/java/README.md diff --git a/exercises/03_architecture/kafka/nodejs/README.md b/resources/03_architecture/kafka/nodejs/README.md similarity index 100% rename from exercises/03_architecture/kafka/nodejs/README.md rename to resources/03_architecture/kafka/nodejs/README.md diff --git a/exercises/03_architecture/kafka/nodejs/consumer.js b/resources/03_architecture/kafka/nodejs/consumer.js similarity index 100% rename from exercises/03_architecture/kafka/nodejs/consumer.js rename to resources/03_architecture/kafka/nodejs/consumer.js diff --git a/exercises/03_architecture/kafka/nodejs/interactiveProducer.js b/resources/03_architecture/kafka/nodejs/interactiveProducer.js similarity index 100% rename from exercises/03_architecture/kafka/nodejs/interactiveProducer.js rename to resources/03_architecture/kafka/nodejs/interactiveProducer.js diff --git a/exercises/03_architecture/kafka/nodejs/package.json b/resources/03_architecture/kafka/nodejs/package.json similarity index 100% rename from exercises/03_architecture/kafka/nodejs/package.json rename to resources/03_architecture/kafka/nodejs/package.json diff --git a/exercises/03_architecture/kafka/nodejs/producer.js b/resources/03_architecture/kafka/nodejs/producer.js similarity index 100% rename from exercises/03_architecture/kafka/nodejs/producer.js rename to resources/03_architecture/kafka/nodejs/producer.js diff --git a/exercises/03_architecture/kafka/python/README.md b/resources/03_architecture/kafka/python/README.md similarity index 100% rename from exercises/03_architecture/kafka/python/README.md rename to resources/03_architecture/kafka/python/README.md diff --git a/exercises/03_architecture/kafka/python/producer.py b/resources/03_architecture/kafka/python/producer.py similarity index 100% rename from exercises/03_architecture/kafka/python/producer.py rename to resources/03_architecture/kafka/python/producer.py diff --git a/exercises/03_architecture/kafka/shell/README.md b/resources/03_architecture/kafka/shell/README.md similarity index 100% rename from exercises/03_architecture/kafka/shell/README.md rename to resources/03_architecture/kafka/shell/README.md diff --git a/exercises/03_architecture/kafka/shell/ubuntu.sh b/resources/03_architecture/kafka/shell/ubuntu.sh similarity index 100% rename from exercises/03_architecture/kafka/shell/ubuntu.sh rename to resources/03_architecture/kafka/shell/ubuntu.sh diff --git a/exercises/03_architecture/microservices/README.md b/resources/03_architecture/microservices/README.md similarity index 100% rename from exercises/03_architecture/microservices/README.md rename to resources/03_architecture/microservices/README.md diff --git a/exercises/03_architecture/microservices/api/Dockerfile b/resources/03_architecture/microservices/api/Dockerfile similarity index 100% rename from exercises/03_architecture/microservices/api/Dockerfile rename to resources/03_architecture/microservices/api/Dockerfile diff --git a/exercises/03_architecture/microservices/api/server.js b/resources/03_architecture/microservices/api/server.js similarity index 100% rename from exercises/03_architecture/microservices/api/server.js rename to resources/03_architecture/microservices/api/server.js diff --git a/exercises/03_architecture/microservices/docker-compose.yml b/resources/03_architecture/microservices/docker-compose.yml similarity index 100% rename from exercises/03_architecture/microservices/docker-compose.yml rename to resources/03_architecture/microservices/docker-compose.yml diff --git a/exercises/03_architecture/microservices/logs/Dockerfile b/resources/03_architecture/microservices/logs/Dockerfile similarity index 100% rename from exercises/03_architecture/microservices/logs/Dockerfile rename to resources/03_architecture/microservices/logs/Dockerfile diff --git a/exercises/03_architecture/microservices/logs/server.js b/resources/03_architecture/microservices/logs/server.js similarity index 100% rename from exercises/03_architecture/microservices/logs/server.js rename to resources/03_architecture/microservices/logs/server.js diff --git a/exercises/03_architecture/microservices/mysql/Dockerfile b/resources/03_architecture/microservices/mysql/Dockerfile similarity index 100% rename from exercises/03_architecture/microservices/mysql/Dockerfile rename to resources/03_architecture/microservices/mysql/Dockerfile diff --git a/exercises/03_architecture/microservices/redis/Dockerfile b/resources/03_architecture/microservices/redis/Dockerfile similarity index 100% rename from exercises/03_architecture/microservices/redis/Dockerfile rename to resources/03_architecture/microservices/redis/Dockerfile diff --git a/exercises/03_architecture/queue/kue.js b/resources/03_architecture/queue/kue.js similarity index 100% rename from exercises/03_architecture/queue/kue.js rename to resources/03_architecture/queue/kue.js diff --git a/exercises/03_architecture/queue/redis-publish.js b/resources/03_architecture/queue/redis-publish.js similarity index 100% rename from exercises/03_architecture/queue/redis-publish.js rename to resources/03_architecture/queue/redis-publish.js diff --git a/exercises/03_architecture/queue/redis-publish.py b/resources/03_architecture/queue/redis-publish.py similarity index 100% rename from exercises/03_architecture/queue/redis-publish.py rename to resources/03_architecture/queue/redis-publish.py diff --git a/exercises/03_architecture/queue/redis-subscribe.js b/resources/03_architecture/queue/redis-subscribe.js similarity index 100% rename from exercises/03_architecture/queue/redis-subscribe.js rename to resources/03_architecture/queue/redis-subscribe.js diff --git a/exercises/03_architecture/queue/redis_subscribe.py b/resources/03_architecture/queue/redis_subscribe.py similarity index 100% rename from exercises/03_architecture/queue/redis_subscribe.py rename to resources/03_architecture/queue/redis_subscribe.py diff --git a/exercises/04_agile_dev/01_sensor_module/ESP8266_micro_python.md b/resources/04_agile_dev/01_sensor_module/ESP8266_micro_python.md similarity index 100% rename from exercises/04_agile_dev/01_sensor_module/ESP8266_micro_python.md rename to resources/04_agile_dev/01_sensor_module/ESP8266_micro_python.md diff --git a/exercises/04_agile_dev/01_sensor_module/README.md b/resources/04_agile_dev/01_sensor_module/README.md similarity index 83% rename from exercises/04_agile_dev/01_sensor_module/README.md rename to resources/04_agile_dev/01_sensor_module/README.md index 8ed918a..f71925a 100644 --- a/exercises/04_agile_dev/01_sensor_module/README.md +++ b/resources/04_agile_dev/01_sensor_module/README.md @@ -1,5 +1,5 @@ -# The Sensor Module +# Electronic Equipment Congratulations, you have been assigned to develop the sensor module for this project. You will need to apply the skills you have learned on the CHSE programme, on the 307CR module or through your personal learning. @@ -38,7 +38,7 @@ You will be provided with an **ESP8266 Development Module**. ## Sensors -There are a number of sensors that can be used for environmental sensors but it is important that you only pick those that are supported by Arduino libraries. The table below shows some of the most useful ones and includes links to online tutorials. If you identify other useful ones, let the module leader know and they can be added to the list. The ones shown _italicised_ are **not** part of the provided kit. Links are provided to suitable tutorials. +There are a number of sensors that can be used for environmental sensors but it is important that you only pick those that are supported by Arduino libraries. The table below shows some of the most useful ones and includes links to online tutorials. If you identify other useful ones, let the module leader know and they can be added to the list. | Environment | Sensor | Interface | | ----------------------------------------------------- | ------------ | ---------- | @@ -81,24 +81,32 @@ As part of this project you may want to add a screen to display useful informati The following items will be in the kit issued to your team. Make sure you check everything is there before signing for it. | Equipment | Cost | -| ----------------------------------------------------------- | ----: | -| [NodeMCU ESP8266 CP2102 v3](http://amzn.eu/iFhW1f4) | £6.99 | -| [Micro-USB cable 30cm](http://amzn.eu/eJ6z1Ux) | £3.99 | -| [Breadboard](http://amzn.eu/4r8UL9Q) | £1.56 | -| [Jumper wires x65](http://amzn.eu/ejw4p3Q) | £3.95 | -| [Temperature sensor module DS18B20](http://amzn.eu/6h2mzBC) | £1.35 | -| [Temperature/Humidity module DHT11](http://amzn.eu/glrhIqs) | £1.46 | -| [Gas sensor MQ-135](http://amzn.eu/h573jLl) | £5.60 | -| [Light sensor GY-2561 TSL2561](http://amzn.eu/a07k83G) | £1.62 | -| [Vibration sensor SW-420](http://amzn.eu/crleUBd) | £1.76 | -| [Sound sensor KY-038](http://amzn.eu/3tkqZG2) | £3.60 | -| [Stanley storage box](http://amzn.eu/hyI4x9J) | £7.30 | +| Equipment | Qty | Cost | +| ----------------------------------------------------------- | --: | ----: | +| [Storage box](http://amzn.eu/hyI4x9J) | 1 | £7.30 | +| [NodeMCU ESP8266 CP2102 v3](http://amzn.eu/iFhW1f4) | 1 | £6.99 | +| [Micro-USB cable 30cm](http://amzn.eu/eJ6z1Ux) | 1 | £3.99 | +| [Breadboard](http://amzn.eu/4r8UL9Q) | 2 | £1.56 | +| [Breadboard power supply](http://amzn.eu/3YVPeDC) | 1 | £2.48 | +| [AA Battery Holder to 9v](http://amzn.eu/616kZXO) | 1 | £1.99 | +| [Power Jack to 9v clip](http://amzn.eu/9HzCdCB) | 1 | £1.00 | +| [Jumper wires](http://amzn.eu/ejw4p3Q) | 65 | £3.95 | +| [Mixed resistors](http://amzn.eu/76cxzbo) | - | £1.00 | +| [Mult-coloured LED](http://amzn.eu/88DIvzz) | 6 | £1.00 | +| [RGB LED](http://amzn.eu/in4Ovho) | 4 | £1.00 | +| [Temperature sensor module DS18B20](http://amzn.eu/6h2mzBC) | 1 | £1.35 | +| [Temperature/Humidity module DHT11](http://amzn.eu/glrhIqs) | 1 | £1.46 | +| [Gas sensor MQ-135](http://amzn.eu/h573jLl) | 1 | £5.60 | +| [Light sensor GY-2561 TSL2561](http://amzn.eu/a07k83G) | 1 | £1.62 | +| [Vibration sensor SW-420](http://amzn.eu/crleUBd) | 1 | £1.76 | +| [Sound sensor KY-038](http://amzn.eu/3tkqZG2) | 1 | £3.60 | +| [Ultrasonic sensor HC-SR04](http://amzn.eu/cEqKyuC) | 1 | £1.00 | **NOTE:** One member of the team will have to sign for the kit at the start of the project. Any missing items will be charged at the prices in the table above. ### Basic Electronic Components -As well as the various sensors you will need some basic electronic components. +As well as the various sensors you will need some basic electronic components. These can be obtained from the electronics lab on the second floor of the EEC building. | Component | Qty | | -------------------------------- | --: | @@ -107,37 +115,27 @@ As well as the various sensors you will need some basic electronic components. | Resistor 27K | 5 | | Push button (DP) | 5 | -### Additional Components +### Additional Sensors -Your trip organisers can provide your team with the following components. +Your lab supervisor will be able to provide limited quantities of the following additional sensors. | Equipment | Cost | Qty | | -------------------------------------------------------------- | -----: | --: | -| [USB type-c to Micro-b 15cm cable](http://amzn.eu/0EwGYjA) | £5.51 | 2 | -| [USB to USB-C adapter](http://amzn.eu/6FTTtUW) | £5.49 | 2 | -| [Breadboard power supply](http://amzn.eu/cczLbg7) | £2.48 | 5 | -| [Rechargable 9v battery](http://amzn.eu/6kKladh) | £5.78 | 5 | | [UV sensor VEML6070](http://amzn.eu/grXhZ2C) | £10.42 | 5 | | [Dust sensor GP2Y1010AU0F](http://amzn.eu/5xqZT1y) | £8.76 | 5 | | [GY-NEO6MV2 NEO-6M GPS Module](http://amzn.eu/j07kOl8) | £5.99 | 5 | | [Real time clock DS3231](http://amzn.eu/0VfAOTr) | £4.99 | 2 | | [0.96 ssd1306 i2c OLED](http://amzn.eu/g3Be2pk) | £6.99 | 5 | -| [ESP8266 ESP-12E module](http://amzn.eu/b9CUYlZ) | £2.03 | 2 | -| [MicroUSB 3.3v/5v regulator](https://goo.gl/HKv8jr) | £2.99 | 2 | -| [Male header pins 0.1" pitch (40 pin)](http://amzn.eu/cmXmuGU) | £5.99 | 50 | -| [Male header pins 2mm pitch (40 pin)](http://amzn.eu/eXAIKxn) | £1.27 | 10 | -| [USB TTL serial cable](http://amzn.eu/3aLUqLr) | £5.99 | 2 | ## Lab Equipment -During your project you may need to troubleshoot your circuits. There are a number of tools that can be requested from the trip organisers. Make sure you have researched their purpose and how they are used, the trip organisers can help. +During your project you may need to troubleshoot your circuits. There are a number of tools that can be accessed in the Electronics lab on the second floor of the ECB. Make sure you have researched their purpose and how they are used. | Equipment | Cost | Qty | | ------------------------------------------------------ | -----: | --: | | [Multimeter](http://amzn.eu/gMtjFrh) | £3.82 | 2 | | [USB voltage/current meter](http://amzn.eu/0Hdmuff) | £3.99 | 2 | -| [USB soldering iron](http://amzn.eu/0yH0Mbu) | £6.95 | 1 | -| [Solder (1mm)](http://amzn.eu/d9PRCrz) | £8.02 | 1 | +| [Soldering iron](http://amzn.eu/0yH0Mbu) | £6.95 | 1 | | [Bus pirate v4](http://amzn.eu/f8b1qrQ) | £38.99 | 1 | | [Bus pirate probes](http://amzn.eu/cbTu20s) | £5.99 | 1 | | [Open workbench logic sniffer](http://amzn.eu/8Pl4BUy) | £62.99 | 1 | diff --git a/exercises/04_agile_dev/01_sensor_module/extension_tasks.md b/resources/04_agile_dev/01_sensor_module/extension_tasks.md similarity index 94% rename from exercises/04_agile_dev/01_sensor_module/extension_tasks.md rename to resources/04_agile_dev/01_sensor_module/extension_tasks.md index 235320a..0ec7c9a 100644 --- a/exercises/04_agile_dev/01_sensor_module/extension_tasks.md +++ b/resources/04_agile_dev/01_sensor_module/extension_tasks.md @@ -8,7 +8,7 @@ There are a lot of ways this project can be extended. Now you have a prototype sensor module can you design a custom PCB ready for manufacture? 1. Start by downloading the [Fritzing](http://fritzing.org/home/) software and reproduce your breadboard layout. - 1. You will need to install [additional components](https://github.com/squix78/esp8266-fritzing-parts). + 1. You will need to install [additional components](https://github.com/squix78/esp8266-fritzing-parts). 2. Switch to the Schematic tab and refine your circuit schematic. 3. Finally use the PCB tab to design a compact PCB. 4. Calculate the Bill Of Materials (BOM) for each board. diff --git a/exercises/04_agile_dev/02_web_api/README.md b/resources/04_agile_dev/02_web_api/README.md similarity index 100% rename from exercises/04_agile_dev/02_web_api/README.md rename to resources/04_agile_dev/02_web_api/README.md diff --git a/exercises/04_agile_dev/02_web_api/mqtt.md b/resources/04_agile_dev/02_web_api/mqtt.md similarity index 100% rename from exercises/04_agile_dev/02_web_api/mqtt.md rename to resources/04_agile_dev/02_web_api/mqtt.md diff --git a/exercises/04_agile_dev/03_smartphone_app/README.md b/resources/04_agile_dev/03_smartphone_app/README.md similarity index 100% rename from exercises/04_agile_dev/03_smartphone_app/README.md rename to resources/04_agile_dev/03_smartphone_app/README.md diff --git a/exercises/05_code_quality/03_dependencies/java/Lister.java b/resources/05_automated_test/01_unit/Java/Lister.java similarity index 100% rename from exercises/05_code_quality/03_dependencies/java/Lister.java rename to resources/05_automated_test/01_unit/Java/Lister.java diff --git a/exercises/05_code_quality/05_unit/Java/spec/ListerTest.java b/resources/05_automated_test/01_unit/Java/spec/ListerTest.java similarity index 100% rename from exercises/05_code_quality/05_unit/Java/spec/ListerTest.java rename to resources/05_automated_test/01_unit/Java/spec/ListerTest.java diff --git a/exercises/05_code_quality/05_unit/Swift/.build/build.db b/resources/05_automated_test/01_unit/Swift/.build/build.db similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/build.db rename to resources/05_automated_test/01_unit/Swift/.build/build.db diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug.yaml b/resources/05_automated_test/01_unit/Swift/.build/debug.yaml similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug.yaml rename to resources/05_automated_test/01_unit/Swift/.build/debug.yaml diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister.d b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister.d similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister.d rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister.d diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister.swift.o b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister.swift.o similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister.swift.o rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister.swift.o diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister.swiftdeps b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister.swiftdeps similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister.swiftdeps rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister.swiftdeps diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftdoc b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftdoc similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftdoc rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftdoc diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftmodule b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftmodule similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftmodule rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/Lister~partial.swiftmodule diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/master.swiftdeps b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/master.swiftdeps similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/master.swiftdeps rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/master.swiftdeps diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/output-file-map.json b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/output-file-map.json similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.build/output-file-map.json rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.build/output-file-map.json diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.swiftdoc b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.swiftdoc similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.swiftdoc rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.swiftdoc diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.swiftmodule b/resources/05_automated_test/01_unit/Swift/.build/debug/Lister.swiftmodule similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/Lister.swiftmodule rename to resources/05_automated_test/01_unit/Swift/.build/debug/Lister.swiftmodule diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/Info.plist b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/Info.plist similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/Info.plist rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/Info.plist diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Info.plist b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Info.plist similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Info.plist rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Info.plist diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Resources/DWARF/ListerPackageTests b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Resources/DWARF/ListerPackageTests similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Resources/DWARF/ListerPackageTests rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerPackageTests.xctest/Contents/MacOS/ListerPackageTests.dSYM/Contents/Resources/DWARF/ListerPackageTests diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests.d b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests.d similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests.d rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests.d diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests.swift.o b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests.swift.o similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests.swift.o rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests.swift.o diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests.swiftdeps b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests.swiftdeps similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests.swiftdeps rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests.swiftdeps diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftdoc b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftdoc similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftdoc rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftdoc diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftmodule b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftmodule similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftmodule rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/ListerTests~partial.swiftmodule diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/master.swiftdeps b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/master.swiftdeps similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/master.swiftdeps rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/master.swiftdeps diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/output-file-map.json b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/output-file-map.json similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.build/output-file-map.json rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.build/output-file-map.json diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.swiftdoc b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.swiftdoc similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.swiftdoc rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.swiftdoc diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.swiftmodule b/resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.swiftmodule similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ListerTests.swiftmodule rename to resources/05_automated_test/01_unit/Swift/.build/debug/ListerTests.swiftmodule diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/AppKit-1LWHB1MWS5AWP.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/AppKit-1LWHB1MWS5AWP.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/AppKit-1LWHB1MWS5AWP.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/AppKit-1LWHB1MWS5AWP.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ApplicationServices-SV8UEN8TMBAR.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ApplicationServices-SV8UEN8TMBAR.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ApplicationServices-SV8UEN8TMBAR.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ApplicationServices-SV8UEN8TMBAR.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CFNetwork-WOPYBVYTVV3P.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CFNetwork-WOPYBVYTVV3P.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CFNetwork-WOPYBVYTVV3P.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CFNetwork-WOPYBVYTVV3P.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreData-1DHIL9VVBSYDQ.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreData-1DHIL9VVBSYDQ.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreData-1DHIL9VVBSYDQ.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreData-1DHIL9VVBSYDQ.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreFoundation-RZX25862PY17.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreFoundation-RZX25862PY17.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreFoundation-RZX25862PY17.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreFoundation-RZX25862PY17.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreGraphics-MC4FPA2MN9QR.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreGraphics-MC4FPA2MN9QR.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreGraphics-MC4FPA2MN9QR.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreGraphics-MC4FPA2MN9QR.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreImage-SV8UEN8TMBAR.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreImage-SV8UEN8TMBAR.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreImage-SV8UEN8TMBAR.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreImage-SV8UEN8TMBAR.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreServices-2SRTBNLRER772.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreServices-2SRTBNLRER772.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreServices-2SRTBNLRER772.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreServices-2SRTBNLRER772.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreText-4BX5WGXMXE7W.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreText-4BX5WGXMXE7W.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreText-4BX5WGXMXE7W.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreText-4BX5WGXMXE7W.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreVideo-J9HZM7HTOIXH.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreVideo-J9HZM7HTOIXH.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreVideo-J9HZM7HTOIXH.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/CoreVideo-J9HZM7HTOIXH.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Darwin-1IVCWVLR6MT9T.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Darwin-1IVCWVLR6MT9T.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Darwin-1IVCWVLR6MT9T.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Darwin-1IVCWVLR6MT9T.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/DiskArbitration-1YS8ZT252YZXQ.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/DiskArbitration-1YS8ZT252YZXQ.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/DiskArbitration-1YS8ZT252YZXQ.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/DiskArbitration-1YS8ZT252YZXQ.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Dispatch-2M9AOUJY3TW9V.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Dispatch-2M9AOUJY3TW9V.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Dispatch-2M9AOUJY3TW9V.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Dispatch-2M9AOUJY3TW9V.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Foundation-2FJBXN8U6QRTS.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Foundation-2FJBXN8U6QRTS.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Foundation-2FJBXN8U6QRTS.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Foundation-2FJBXN8U6QRTS.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOKit-2OU2NY71U259J.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOKit-2OU2NY71U259J.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOKit-2OU2NY71U259J.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOKit-2OU2NY71U259J.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOSurface-GCVS5NOA7EOF.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOSurface-GCVS5NOA7EOF.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOSurface-GCVS5NOA7EOF.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/IOSurface-GCVS5NOA7EOF.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ImageIO-3MTK4VGYXNJP8.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ImageIO-3MTK4VGYXNJP8.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ImageIO-3MTK4VGYXNJP8.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ImageIO-3MTK4VGYXNJP8.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/MachO-2UHIFKDZCI0YX.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/MachO-2UHIFKDZCI0YX.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/MachO-2UHIFKDZCI0YX.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/MachO-2UHIFKDZCI0YX.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Metal-LZGKTAAK5A7P.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Metal-LZGKTAAK5A7P.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Metal-LZGKTAAK5A7P.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Metal-LZGKTAAK5A7P.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ObjectiveC-EIJ0EPUNA6LP.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ObjectiveC-EIJ0EPUNA6LP.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ObjectiveC-EIJ0EPUNA6LP.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/ObjectiveC-EIJ0EPUNA6LP.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/OpenGL-1VU9F7LS7N5R1.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/OpenGL-1VU9F7LS7N5R1.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/OpenGL-1VU9F7LS7N5R1.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/OpenGL-1VU9F7LS7N5R1.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/QuartzCore-1LT8XAPDT2LBF.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/QuartzCore-1LT8XAPDT2LBF.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/QuartzCore-1LT8XAPDT2LBF.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/QuartzCore-1LT8XAPDT2LBF.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Security-2RB2R7QDU33DQ.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Security-2RB2R7QDU33DQ.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Security-2RB2R7QDU33DQ.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/Security-2RB2R7QDU33DQ.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/SwiftShims-1HJGLIW7H35BO.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/SwiftShims-1HJGLIW7H35BO.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/SwiftShims-1HJGLIW7H35BO.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/SwiftShims-1HJGLIW7H35BO.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XCTest-2NCTUXJWAFHPE.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XCTest-2NCTUXJWAFHPE.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XCTest-2NCTUXJWAFHPE.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XCTest-2NCTUXJWAFHPE.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XPC-3LIAJY90PG03M.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XPC-3LIAJY90PG03M.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XPC-3LIAJY90PG03M.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/XPC-3LIAJY90PG03M.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_intrinsics-1QSLWXKIZ9CUS.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_intrinsics-1QSLWXKIZ9CUS.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_intrinsics-1QSLWXKIZ9CUS.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_intrinsics-1QSLWXKIZ9CUS.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_stddef_max_align_t-1QSLWXKIZ9CUS.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_stddef_max_align_t-1QSLWXKIZ9CUS.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_stddef_max_align_t-1QSLWXKIZ9CUS.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/_Builtin_stddef_max_align_t-1QSLWXKIZ9CUS.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/launch-1IVCWVLR6MT9T.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/launch-1IVCWVLR6MT9T.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/launch-1IVCWVLR6MT9T.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/launch-1IVCWVLR6MT9T.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/libkern-1IVCWVLR6MT9T.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/libkern-1IVCWVLR6MT9T.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/libkern-1IVCWVLR6MT9T.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/libkern-1IVCWVLR6MT9T.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/os_object-1IVCWVLR6MT9T.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/os_object-1IVCWVLR6MT9T.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/os_object-1IVCWVLR6MT9T.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/os_object-1IVCWVLR6MT9T.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/simd-267O87N2FDEWY.pcm b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/simd-267O87N2FDEWY.pcm similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/simd-267O87N2FDEWY.pcm rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/Q3KKH3V7UU86/simd-267O87N2FDEWY.pcm diff --git a/exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/modules.timestamp b/resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/modules.timestamp similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/.build/debug/ModuleCache/modules.timestamp rename to resources/05_automated_test/01_unit/Swift/.build/debug/ModuleCache/modules.timestamp diff --git a/exercises/05_code_quality/05_unit/Swift/Package.swift b/resources/05_automated_test/01_unit/Swift/Package.swift similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/Package.swift rename to resources/05_automated_test/01_unit/Swift/Package.swift diff --git a/exercises/05_code_quality/05_unit/Swift/README.md b/resources/05_automated_test/01_unit/Swift/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/README.md rename to resources/05_automated_test/01_unit/Swift/README.md diff --git a/exercises/05_code_quality/01_linting/swift/Lister.swift b/resources/05_automated_test/01_unit/Swift/Sources/Lister.swift similarity index 100% rename from exercises/05_code_quality/01_linting/swift/Lister.swift rename to resources/05_automated_test/01_unit/Swift/Sources/Lister.swift diff --git a/exercises/05_code_quality/05_unit/Swift/Tests/LinuxMain.swift b/resources/05_automated_test/01_unit/Swift/Tests/LinuxMain.swift similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/Tests/LinuxMain.swift rename to resources/05_automated_test/01_unit/Swift/Tests/LinuxMain.swift diff --git a/exercises/05_code_quality/05_unit/Swift/Tests/ListerTests/ListerTests.swift b/resources/05_automated_test/01_unit/Swift/Tests/ListerTests/ListerTests.swift similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/Tests/ListerTests/ListerTests.swift rename to resources/05_automated_test/01_unit/Swift/Tests/ListerTests/ListerTests.swift diff --git a/resources/05_automated_test/01_unit/cpp/Maths.cpp b/resources/05_automated_test/01_unit/cpp/Maths.cpp new file mode 100644 index 0000000..3f7b3ae --- /dev/null +++ b/resources/05_automated_test/01_unit/cpp/Maths.cpp @@ -0,0 +1,10 @@ + +#include "Maths.h" + +// this is the function we are going to test +// note that there are no API calls in this fucntion +// the function only contains our business logic. +int Maths::add(int a, int b) { + return a + b; +} + diff --git a/resources/05_automated_test/01_unit/cpp/Maths.h b/resources/05_automated_test/01_unit/cpp/Maths.h new file mode 100644 index 0000000..b793a87 --- /dev/null +++ b/resources/05_automated_test/01_unit/cpp/Maths.h @@ -0,0 +1,8 @@ + + + +class Maths { + public: + int add(int, int); // this is the function we are going to test +}; + diff --git a/resources/05_automated_test/01_unit/cpp/README.md b/resources/05_automated_test/01_unit/cpp/README.md new file mode 100644 index 0000000..c2facf5 --- /dev/null +++ b/resources/05_automated_test/01_unit/cpp/README.md @@ -0,0 +1,103 @@ + +## Unit Testing C++ Code + +In this tutorial we will be using the [Google Test](https://github.com/google/googletest) unit testing framework. + +## Installation + +Rather than provide instructions for different platforms there are already detailed instruction for [Linux](https://stackoverflow.com/questions/13513905/how-to-setup-googletest-as-a-shared-library-on-linux). [MacOS](https://github.com/iat-cener/tonatiuh/wiki/Installing-Google-Test-For-Mac) and [Windows](https://github.com/iat-cener/tonatiuh/wiki/Installing-Google-Test-For-Windows). + +## Getting Started + +Here is a [really good tutorial](https://www.ibm.com/developerworks/aix/library/au-googletestingframework.html) from IBM showing you how to write your first unit test suite. + +## Unit Testing Arduino Code + +https://stackoverflow.com/questions/780819/how-can-i-unit-test-arduino-code + +https://github.com/mmurdoch/arduinounit/ + +### Arduino Emulators + +https://github.com/maniacbug/ncore + +https://github.com/buserror/simavr + +## GitHub CovCom for CxxTest handout: + +https://github.com/covcom/122COM/blob/2016-17_jan/testinglecture_handout.pdf + +## Creating your first Cxx Test + +### Install CxxTest and get g++ + +This process can be done from command line on Windows or Mac. Just make sure you have a C++ compiler installed (e.g. g++) and have downloaded CxxTest. +You can download CxxTest from [here](https://sourceforge.net/projects/cxxtest/files/cxxtest/) + +Once you have CxxTest installed you can unzip to a suitable directory on your system. + +On the University PCs g++ is **not** installed by default! In order to get it you can launch codeblocks from the apps anywhere system, and then you will find the g++ in the directory: C:\Program Files (x86)\CodeBlocks\MinGW\bin\g++.exe + +### Creating your first Cxx Test Suite + +Unit testing involes testing your own code. I.e. you should not be testing any API or library calls. You will need to seperate your source code from your API calls. I suggest creating a seperate class with methods for your business logic code (i.e. any code **not** invloved wih input or output API calls). + +So in my example I have Maths.h and Maths.cpp which contains my business logic (a simple add function). For yours, you may be calculating a moving average etc. +Then you will need to write a test suite for CxxTest to work, let's call it - TestSuiteCXX.h +You can see an example for the structure of a Cxx test suite [here](http://cxxtest.com/guide.html). + +We can run the test suite from command line with the following 3 statements: + +cxxtestgen --error-printer -o runner.cpp MyTestSuite1.h + +g++ -o runner -I$CXXTEST runner.cpp + +./runner + +This will give you output such as: +Running cxxtest tests (1 test).OK! + +Now, you **will** need to modify these commands based on the your project paths on the system you use and the CxxTest and g++ install directories etc. +On my system (Uni PC) the commands look like: + +H:\_Lecturer\302CEM\cxxtest-4.4\cxxtest-4.4\bin\cxxtestgen --error-printer -o runner.cpp TestSuiteCxx.h + +"C:\Program Files (x86)\CodeBlocks\MinGW\bin\g++" -o runner -IH:\_Lecturer\302CEM\cxxtest-4.4\cxxtest-4.4 runner.cpp Maths.cpp + +.\runner + +Note on Uni PCs I manged to get this working through the default windows command line - cmd.exe. Note Windows powershell.exe did not work for me! + + +Once you have this working from command line you can then investigate automated testing via creating you own custom build scripts. + +The build process including tests can also be automated (i.e. automated testing) via a build system e.g. Makefiles, an example is here: +https://emou.wordpress.com/2009/10/02/unit-testing-in-c-using-cxxtest/ + + +## Switching from the Arduino IDE to using VSCode + +**Optionally** you can switch to using the VSCode IDE for Arduino development. This IDE has numerous benefits over the Arduino IDE. + +Steps to setting up VSCode for Arduino Development: +1. Install Arduino IDE +2. Install VS Code +3. In VS Code Open Folder for storing your C++ project and create C++ files and Arduino .ino files. +4. Install C++ extension in VSCode +5. Install Arduino extension in VSCode +6. In VSCode User Settings set: + +```json +{ + "arduino.additionalUrls": "http://arduino.esp8266.com/stable/package_esp8266com_index.json" +} +``` + +7. In VSCode Board Manager Install esp8266 +8. Ctrl-Shift-P  Change Board Type  Adafruit HUZZAH ESP8266 +9. Set c_cpp_properties.json with paths to Arduino install +10. Force Intellisense to use the "Tag Parser" in the User Settings: +11. Set up the c_cpp_properties.json +https://github.com/Microsoft/vscode-arduino/issues/438 + + diff --git a/resources/05_automated_test/01_unit/cpp/TestSuiteCxx.h b/resources/05_automated_test/01_unit/cpp/TestSuiteCxx.h new file mode 100644 index 0000000..041d3ea --- /dev/null +++ b/resources/05_automated_test/01_unit/cpp/TestSuiteCxx.h @@ -0,0 +1,24 @@ +// TestSuiteCxx.h +// This file contains our Cxx Test Suite which is defining our tests for our code in Maths.cpp + +#include +#include "Maths.h" + +class TestSuiteCxx : public CxxTest::TestSuite +{ +public: + void testAddition1(void) + { + Maths myObject; + TS_ASSERT(myObject.add(1, 1) > 1); + TS_ASSERT_EQUALS(myObject.add(1, 1), 2); + } + + void testAddition2(void) + { + Maths myObject; + TS_TRACE("Starting addition2 test"); + TS_ASSERT_EQUALS(myObject.add(2, 2), 5); // this will fail our test because our test has errors + TS_TRACE("Finishing addition2 test"); + } +}; diff --git a/resources/05_automated_test/01_unit/cpp/runner.cpp b/resources/05_automated_test/01_unit/cpp/runner.cpp new file mode 100644 index 0000000..5e8768e --- /dev/null +++ b/resources/05_automated_test/01_unit/cpp/runner.cpp @@ -0,0 +1,43 @@ +/* Generated file, do not edit */ + +#ifndef CXXTEST_RUNNING +#define CXXTEST_RUNNING +#endif + +#define _CXXTEST_HAVE_STD +#include +#include +#include +#include +#include +#include + +int main( int argc, char *argv[] ) { + int status; + CxxTest::ErrorPrinter tmp; + CxxTest::RealWorldDescription::_worldName = "cxxtest"; + status = CxxTest::Main< CxxTest::ErrorPrinter >( tmp, argc, argv ); + return status; +} +bool suite_TestSuiteCxx_init = false; +#include "TestSuiteCxx.h" + +static TestSuiteCxx suite_TestSuiteCxx; + +static CxxTest::List Tests_TestSuiteCxx = { 0, 0 }; +CxxTest::StaticSuiteDescription suiteDescription_TestSuiteCxx( "TestSuiteCxx.h", 7, "TestSuiteCxx", suite_TestSuiteCxx, Tests_TestSuiteCxx ); + +static class TestDescription_suite_TestSuiteCxx_testAddition1 : public CxxTest::RealTestDescription { +public: + TestDescription_suite_TestSuiteCxx_testAddition1() : CxxTest::RealTestDescription( Tests_TestSuiteCxx, suiteDescription_TestSuiteCxx, 10, "testAddition1" ) {} + void runTest() { suite_TestSuiteCxx.testAddition1(); } +} testDescription_suite_TestSuiteCxx_testAddition1; + +static class TestDescription_suite_TestSuiteCxx_testAddition2 : public CxxTest::RealTestDescription { +public: + TestDescription_suite_TestSuiteCxx_testAddition2() : CxxTest::RealTestDescription( Tests_TestSuiteCxx, suiteDescription_TestSuiteCxx, 17, "testAddition2" ) {} + void runTest() { suite_TestSuiteCxx.testAddition2(); } +} testDescription_suite_TestSuiteCxx_testAddition2; + +#include +const char* CxxTest::RealWorldDescription::_worldName = "cxxtest"; diff --git a/resources/05_automated_test/01_unit/cpp/runner.exe b/resources/05_automated_test/01_unit/cpp/runner.exe new file mode 100644 index 0000000..47f9884 Binary files /dev/null and b/resources/05_automated_test/01_unit/cpp/runner.exe differ diff --git a/exercises/05_code_quality/05_unit/nodejs/README.md b/resources/05_automated_test/01_unit/nodejs/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/README.md rename to resources/05_automated_test/01_unit/nodejs/README.md diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/README.md b/resources/05_automated_test/01_unit/nodejs/jasmine/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/README.md rename to resources/05_automated_test/01_unit/nodejs/jasmine/README.md diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/modules/currency.js b/resources/05_automated_test/01_unit/nodejs/jasmine/modules/currency.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/modules/currency.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/modules/currency.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/modules/math.js b/resources/05_automated_test/01_unit/nodejs/jasmine/modules/math.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/modules/math.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/modules/math.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/package.json b/resources/05_automated_test/01_unit/nodejs/jasmine/package.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/package.json rename to resources/05_automated_test/01_unit/nodejs/jasmine/package.json diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/parameterised.js b/resources/05_automated_test/01_unit/nodejs/jasmine/parameterised.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/parameterised.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/parameterised.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/spec/currency-spec.js b/resources/05_automated_test/01_unit/nodejs/jasmine/spec/currency-spec.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/spec/currency-spec.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/spec/currency-spec.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/spec/jasmine.json b/resources/05_automated_test/01_unit/nodejs/jasmine/spec/jasmine.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/spec/jasmine.json rename to resources/05_automated_test/01_unit/nodejs/jasmine/spec/jasmine.json diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/spec/math-spec.js b/resources/05_automated_test/01_unit/nodejs/jasmine/spec/math-spec.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/spec/math-spec.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/spec/math-spec.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/spec/testRunner.js b/resources/05_automated_test/01_unit/nodejs/jasmine/spec/testRunner.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/spec/testRunner.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/spec/testRunner.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/spec/testRunnerTAP.js b/resources/05_automated_test/01_unit/nodejs/jasmine/spec/testRunnerTAP.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/spec/testRunnerTAP.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/spec/testRunnerTAP.js diff --git a/exercises/05_code_quality/05_unit/nodejs/jasmine/spec/testRunnerTerminal.js b/resources/05_automated_test/01_unit/nodejs/jasmine/spec/testRunnerTerminal.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/jasmine/spec/testRunnerTerminal.js rename to resources/05_automated_test/01_unit/nodejs/jasmine/spec/testRunnerTerminal.js diff --git a/exercises/05_code_quality/05_unit/nodejs/mongoDB/modules/shopping.js b/resources/05_automated_test/01_unit/nodejs/mongoDB/modules/shopping.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/mongoDB/modules/shopping.js rename to resources/05_automated_test/01_unit/nodejs/mongoDB/modules/shopping.js diff --git a/exercises/05_code_quality/05_unit/nodejs/mongoDB/package.json b/resources/05_automated_test/01_unit/nodejs/mongoDB/package.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/mongoDB/package.json rename to resources/05_automated_test/01_unit/nodejs/mongoDB/package.json diff --git a/exercises/05_code_quality/05_unit/nodejs/mongoDB/schema/schema.js b/resources/05_automated_test/01_unit/nodejs/mongoDB/schema/schema.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/mongoDB/schema/schema.js rename to resources/05_automated_test/01_unit/nodejs/mongoDB/schema/schema.js diff --git a/exercises/05_code_quality/05_unit/nodejs/mongoDB/spec/jasmine.json b/resources/05_automated_test/01_unit/nodejs/mongoDB/spec/jasmine.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/mongoDB/spec/jasmine.json rename to resources/05_automated_test/01_unit/nodejs/mongoDB/spec/jasmine.json diff --git a/exercises/05_code_quality/05_unit/nodejs/mongoDB/spec/shopping-spec.js b/resources/05_automated_test/01_unit/nodejs/mongoDB/spec/shopping-spec.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/mongoDB/spec/shopping-spec.js rename to resources/05_automated_test/01_unit/nodejs/mongoDB/spec/shopping-spec.js diff --git a/exercises/05_code_quality/05_unit/nodejs/mongoDB/spec/testRunner.js b/resources/05_automated_test/01_unit/nodejs/mongoDB/spec/testRunner.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/mongoDB/spec/testRunner.js rename to resources/05_automated_test/01_unit/nodejs/mongoDB/spec/testRunner.js diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/debug.js b/resources/05_automated_test/01_unit/nodejs/shopping/debug.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/debug.js rename to resources/05_automated_test/01_unit/nodejs/shopping/debug.js diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/index.js b/resources/05_automated_test/01_unit/nodejs/shopping/index.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/index.js rename to resources/05_automated_test/01_unit/nodejs/shopping/index.js diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/modules/shopping.js b/resources/05_automated_test/01_unit/nodejs/shopping/modules/shopping.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/modules/shopping.js rename to resources/05_automated_test/01_unit/nodejs/shopping/modules/shopping.js diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/package.json b/resources/05_automated_test/01_unit/nodejs/shopping/package.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/package.json rename to resources/05_automated_test/01_unit/nodejs/shopping/package.json diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/spec/jasmine.json b/resources/05_automated_test/01_unit/nodejs/shopping/spec/jasmine.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/spec/jasmine.json rename to resources/05_automated_test/01_unit/nodejs/shopping/spec/jasmine.json diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/spec/runTests.js b/resources/05_automated_test/01_unit/nodejs/shopping/spec/runTests.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/spec/runTests.js rename to resources/05_automated_test/01_unit/nodejs/shopping/spec/runTests.js diff --git a/exercises/05_code_quality/05_unit/nodejs/shopping/spec/shopping-spec.js b/resources/05_automated_test/01_unit/nodejs/shopping/spec/shopping-spec.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/shopping/spec/shopping-spec.js rename to resources/05_automated_test/01_unit/nodejs/shopping/spec/shopping-spec.js diff --git a/exercises/05_code_quality/05_unit/nodejs/tap_example/README.md b/resources/05_automated_test/01_unit/nodejs/tap_example/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tap_example/README.md rename to resources/05_automated_test/01_unit/nodejs/tap_example/README.md diff --git a/exercises/05_code_quality/05_unit/nodejs/tap_example/modules/currency.js b/resources/05_automated_test/01_unit/nodejs/tap_example/modules/currency.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tap_example/modules/currency.js rename to resources/05_automated_test/01_unit/nodejs/tap_example/modules/currency.js diff --git a/exercises/05_code_quality/05_unit/nodejs/tap_example/modules/math.js b/resources/05_automated_test/01_unit/nodejs/tap_example/modules/math.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tap_example/modules/math.js rename to resources/05_automated_test/01_unit/nodejs/tap_example/modules/math.js diff --git a/exercises/05_code_quality/05_unit/nodejs/tap_example/package.json b/resources/05_automated_test/01_unit/nodejs/tap_example/package.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tap_example/package.json rename to resources/05_automated_test/01_unit/nodejs/tap_example/package.json diff --git a/exercises/05_code_quality/05_unit/nodejs/tap_example/test/currencyTest.js b/resources/05_automated_test/01_unit/nodejs/tap_example/test/currencyTest.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tap_example/test/currencyTest.js rename to resources/05_automated_test/01_unit/nodejs/tap_example/test/currencyTest.js diff --git a/exercises/05_code_quality/05_unit/nodejs/tap_example/test/mathTest.js b/resources/05_automated_test/01_unit/nodejs/tap_example/test/mathTest.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tap_example/test/mathTest.js rename to resources/05_automated_test/01_unit/nodejs/tap_example/test/mathTest.js diff --git a/exercises/05_code_quality/05_unit/nodejs/tape_example/README.md b/resources/05_automated_test/01_unit/nodejs/tape_example/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tape_example/README.md rename to resources/05_automated_test/01_unit/nodejs/tape_example/README.md diff --git a/exercises/05_code_quality/05_unit/nodejs/tape_example/modules/math.js b/resources/05_automated_test/01_unit/nodejs/tape_example/modules/math.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tape_example/modules/math.js rename to resources/05_automated_test/01_unit/nodejs/tape_example/modules/math.js diff --git a/exercises/05_code_quality/05_unit/nodejs/tape_example/package.json b/resources/05_automated_test/01_unit/nodejs/tape_example/package.json similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tape_example/package.json rename to resources/05_automated_test/01_unit/nodejs/tape_example/package.json diff --git a/exercises/05_code_quality/05_unit/nodejs/tape_example/tests/mathTest.js b/resources/05_automated_test/01_unit/nodejs/tape_example/tests/mathTest.js similarity index 100% rename from exercises/05_code_quality/05_unit/nodejs/tape_example/tests/mathTest.js rename to resources/05_automated_test/01_unit/nodejs/tape_example/tests/mathTest.js diff --git a/exercises/05_code_quality/05_unit/python/pytest/README.md b/resources/05_automated_test/01_unit/python/pytest/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/python/pytest/README.md rename to resources/05_automated_test/01_unit/python/pytest/README.md diff --git a/exercises/05_code_quality/05_unit/python/unittest/README.md b/resources/05_automated_test/01_unit/python/unittest/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/README.md rename to resources/05_automated_test/01_unit/python/unittest/README.md diff --git a/exercises/05_code_quality/05_unit/python/unittest/arithmetic.py b/resources/05_automated_test/01_unit/python/unittest/arithmetic.py similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/arithmetic.py rename to resources/05_automated_test/01_unit/python/unittest/arithmetic.py diff --git a/exercises/05_code_quality/05_unit/python/unittest/mathTest.py b/resources/05_automated_test/01_unit/python/unittest/mathTest.py similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/mathTest.py rename to resources/05_automated_test/01_unit/python/unittest/mathTest.py diff --git a/exercises/05_code_quality/05_unit/python/unittest/setupTeardown.py b/resources/05_automated_test/01_unit/python/unittest/setupTeardown.py similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/setupTeardown.py rename to resources/05_automated_test/01_unit/python/unittest/setupTeardown.py diff --git a/exercises/05_code_quality/05_unit/python/unittest/simpleMathWithTests.py b/resources/05_automated_test/01_unit/python/unittest/simpleMathWithTests.py similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/simpleMathWithTests.py rename to resources/05_automated_test/01_unit/python/unittest/simpleMathWithTests.py diff --git a/exercises/05_code_quality/05_unit/python/unittest/stringsTest.py b/resources/05_automated_test/01_unit/python/unittest/stringsTest.py similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/stringsTest.py rename to resources/05_automated_test/01_unit/python/unittest/stringsTest.py diff --git a/exercises/05_code_quality/05_unit/python/unittest/testArithmetic.py b/resources/05_automated_test/01_unit/python/unittest/testArithmetic.py similarity index 100% rename from exercises/05_code_quality/05_unit/python/unittest/testArithmetic.py rename to resources/05_automated_test/01_unit/python/unittest/testArithmetic.py diff --git a/exercises/05_code_quality/05_unit/web_client/README.md b/resources/05_automated_test/01_unit/web_client/README.md similarity index 100% rename from exercises/05_code_quality/05_unit/web_client/README.md rename to resources/05_automated_test/01_unit/web_client/README.md diff --git a/exercises/05_code_quality/05_unit/web_client/css/styles.css b/resources/05_automated_test/01_unit/web_client/css/styles.css similarity index 100% rename from exercises/05_code_quality/05_unit/web_client/css/styles.css rename to resources/05_automated_test/01_unit/web_client/css/styles.css diff --git a/exercises/05_code_quality/05_unit/web_client/index.html b/resources/05_automated_test/01_unit/web_client/index.html similarity index 100% rename from exercises/05_code_quality/05_unit/web_client/index.html rename to resources/05_automated_test/01_unit/web_client/index.html diff --git a/exercises/05_code_quality/05_unit/web_client/js/shopping.js b/resources/05_automated_test/01_unit/web_client/js/shopping.js similarity index 100% rename from exercises/05_code_quality/05_unit/web_client/js/shopping.js rename to resources/05_automated_test/01_unit/web_client/js/shopping.js diff --git a/exercises/05_code_quality/05_unit/web_client/spec/index.html b/resources/05_automated_test/01_unit/web_client/spec/index.html similarity index 100% rename from exercises/05_code_quality/05_unit/web_client/spec/index.html rename to resources/05_automated_test/01_unit/web_client/spec/index.html diff --git a/exercises/05_code_quality/05_unit/web_client/spec/spec.js b/resources/05_automated_test/01_unit/web_client/spec/spec.js similarity index 100% rename from exercises/05_code_quality/05_unit/web_client/spec/spec.js rename to resources/05_automated_test/01_unit/web_client/spec/spec.js diff --git a/exercises/05_code_quality/07_coverage/cpp/README.md b/resources/05_automated_test/02_coverage/cpp/README.md similarity index 73% rename from exercises/05_code_quality/07_coverage/cpp/README.md rename to resources/05_automated_test/02_coverage/cpp/README.md index 0557185..5b9af1e 100644 --- a/exercises/05_code_quality/07_coverage/cpp/README.md +++ b/resources/05_automated_test/02_coverage/cpp/README.md @@ -11,3 +11,12 @@ When you then run the test programs, you will get a lot of files with the covera `lcov` can create HTML pages with the result, but is also prints the totals of the coverage analysis to `stdout`. So, you would have to build a script that runs lcov, filters the output and reports error or failure depending on the percentage measured. You can set limits for `lcov` to define when the coverage is sufficient or not, but this is only used for the background color in the HTML output. + +## Additional Resources + +Here are some good tutorials showing how to use the `gcov` and `lcov` tools with the `gcc` compiler. + +1. https://codeflu.blog/2014/12/26/using-gcov-and-lcov-to-generate-beautiful-c-code-coverage-statistics/ +2. https://qiaomuf.wordpress.com/2011/05/26/use-gcov-and-lcov-to-know-your-test-coverage/ + + diff --git a/exercises/05_code_quality/07_coverage/nodejs/.eslintignore b/resources/05_automated_test/02_coverage/nodejs/.eslintignore similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/.eslintignore rename to resources/05_automated_test/02_coverage/nodejs/.eslintignore diff --git a/exercises/05_code_quality/07_coverage/nodejs/.eslintrc.json b/resources/05_automated_test/02_coverage/nodejs/.eslintrc.json similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/.eslintrc.json rename to resources/05_automated_test/02_coverage/nodejs/.eslintrc.json diff --git a/exercises/05_code_quality/07_coverage/nodejs/.istanbul.yml b/resources/05_automated_test/02_coverage/nodejs/.istanbul.yml similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/.istanbul.yml rename to resources/05_automated_test/02_coverage/nodejs/.istanbul.yml diff --git a/exercises/05_code_quality/07_coverage/nodejs/README.md b/resources/05_automated_test/02_coverage/nodejs/README.md similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/README.md rename to resources/05_automated_test/02_coverage/nodejs/README.md diff --git a/exercises/05_code_quality/07_coverage/nodejs/debug.js b/resources/05_automated_test/02_coverage/nodejs/debug.js similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/debug.js rename to resources/05_automated_test/02_coverage/nodejs/debug.js diff --git a/exercises/05_code_quality/07_coverage/nodejs/index.js b/resources/05_automated_test/02_coverage/nodejs/index.js similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/index.js rename to resources/05_automated_test/02_coverage/nodejs/index.js diff --git a/exercises/05_code_quality/07_coverage/nodejs/modules/shopping.js b/resources/05_automated_test/02_coverage/nodejs/modules/shopping.js similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/modules/shopping.js rename to resources/05_automated_test/02_coverage/nodejs/modules/shopping.js diff --git a/exercises/05_code_quality/07_coverage/nodejs/package.json b/resources/05_automated_test/02_coverage/nodejs/package.json similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/package.json rename to resources/05_automated_test/02_coverage/nodejs/package.json diff --git a/exercises/05_code_quality/07_coverage/nodejs/spec/jasmine.json b/resources/05_automated_test/02_coverage/nodejs/spec/jasmine.json similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/spec/jasmine.json rename to resources/05_automated_test/02_coverage/nodejs/spec/jasmine.json diff --git a/exercises/05_code_quality/07_coverage/nodejs/spec/runTests.js b/resources/05_automated_test/02_coverage/nodejs/spec/runTests.js similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/spec/runTests.js rename to resources/05_automated_test/02_coverage/nodejs/spec/runTests.js diff --git a/exercises/05_code_quality/07_coverage/nodejs/spec/shopping-spec.js b/resources/05_automated_test/02_coverage/nodejs/spec/shopping-spec.js similarity index 100% rename from exercises/05_code_quality/07_coverage/nodejs/spec/shopping-spec.js rename to resources/05_automated_test/02_coverage/nodejs/spec/shopping-spec.js diff --git a/exercises/05_code_quality/08_tap/README.md b/resources/05_automated_test/03_tap/README.md similarity index 100% rename from exercises/05_code_quality/08_tap/README.md rename to resources/05_automated_test/03_tap/README.md diff --git a/exercises/05_code_quality/01_linting/README.md b/resources/07_non_func/01_linting/README.md similarity index 100% rename from exercises/05_code_quality/01_linting/README.md rename to resources/07_non_func/01_linting/README.md diff --git a/exercises/05_code_quality/01_linting/cpp/CPPLINT.cfg b/resources/07_non_func/01_linting/cpp/CPPLINT.cfg similarity index 100% rename from exercises/05_code_quality/01_linting/cpp/CPPLINT.cfg rename to resources/07_non_func/01_linting/cpp/CPPLINT.cfg diff --git a/exercises/05_code_quality/01_linting/cpp/README.md b/resources/07_non_func/01_linting/cpp/README.md similarity index 100% rename from exercises/05_code_quality/01_linting/cpp/README.md rename to resources/07_non_func/01_linting/cpp/README.md diff --git a/exercises/05_code_quality/01_linting/java/Lister.java b/resources/07_non_func/01_linting/java/Lister.java similarity index 100% rename from exercises/05_code_quality/01_linting/java/Lister.java rename to resources/07_non_func/01_linting/java/Lister.java diff --git a/exercises/05_code_quality/01_linting/java/README.md b/resources/07_non_func/01_linting/java/README.md similarity index 100% rename from exercises/05_code_quality/01_linting/java/README.md rename to resources/07_non_func/01_linting/java/README.md diff --git a/exercises/05_code_quality/01_linting/java/checkstyle-8.5-all.jar b/resources/07_non_func/01_linting/java/checkstyle-8.5-all.jar similarity index 100% rename from exercises/05_code_quality/01_linting/java/checkstyle-8.5-all.jar rename to resources/07_non_func/01_linting/java/checkstyle-8.5-all.jar diff --git a/exercises/05_code_quality/01_linting/java/google_checks.xml b/resources/07_non_func/01_linting/java/google_checks.xml similarity index 100% rename from exercises/05_code_quality/01_linting/java/google_checks.xml rename to resources/07_non_func/01_linting/java/google_checks.xml diff --git a/exercises/05_code_quality/01_linting/nodejs/README.md b/resources/07_non_func/01_linting/nodejs/README.md similarity index 100% rename from exercises/05_code_quality/01_linting/nodejs/README.md rename to resources/07_non_func/01_linting/nodejs/README.md diff --git a/exercises/05_code_quality/01_linting/nodejs/debug.js b/resources/07_non_func/01_linting/nodejs/debug.js similarity index 100% rename from exercises/05_code_quality/01_linting/nodejs/debug.js rename to resources/07_non_func/01_linting/nodejs/debug.js diff --git a/exercises/05_code_quality/01_linting/nodejs/index.js b/resources/07_non_func/01_linting/nodejs/index.js similarity index 100% rename from exercises/05_code_quality/01_linting/nodejs/index.js rename to resources/07_non_func/01_linting/nodejs/index.js diff --git a/exercises/05_code_quality/01_linting/nodejs/modules/shopping.js b/resources/07_non_func/01_linting/nodejs/modules/shopping.js similarity index 100% rename from exercises/05_code_quality/01_linting/nodejs/modules/shopping.js rename to resources/07_non_func/01_linting/nodejs/modules/shopping.js diff --git a/exercises/05_code_quality/01_linting/nodejs/package.json b/resources/07_non_func/01_linting/nodejs/package.json similarity index 100% rename from exercises/05_code_quality/01_linting/nodejs/package.json rename to resources/07_non_func/01_linting/nodejs/package.json diff --git a/exercises/05_code_quality/01_linting/swift/.swiftlint.yml b/resources/07_non_func/01_linting/swift/.swiftlint.yml similarity index 100% rename from exercises/05_code_quality/01_linting/swift/.swiftlint.yml rename to resources/07_non_func/01_linting/swift/.swiftlint.yml diff --git a/exercises/05_code_quality/01_linting/swift/.tailor.yml b/resources/07_non_func/01_linting/swift/.tailor.yml similarity index 100% rename from exercises/05_code_quality/01_linting/swift/.tailor.yml rename to resources/07_non_func/01_linting/swift/.tailor.yml diff --git a/exercises/05_code_quality/05_unit/Swift/Sources/Lister.swift b/resources/07_non_func/01_linting/swift/Lister.swift similarity index 100% rename from exercises/05_code_quality/05_unit/Swift/Sources/Lister.swift rename to resources/07_non_func/01_linting/swift/Lister.swift diff --git a/exercises/05_code_quality/01_linting/swift/README.md b/resources/07_non_func/01_linting/swift/README.md similarity index 100% rename from exercises/05_code_quality/01_linting/swift/README.md rename to resources/07_non_func/01_linting/swift/README.md diff --git a/exercises/05_code_quality/02_code_duplication/README.md b/resources/07_non_func/02_code_duplication/README.md similarity index 100% rename from exercises/05_code_quality/02_code_duplication/README.md rename to resources/07_non_func/02_code_duplication/README.md diff --git a/exercises/05_code_quality/02_code_duplication/nodejs/.cpd.yml b/resources/07_non_func/02_code_duplication/nodejs/.cpd.yml similarity index 100% rename from exercises/05_code_quality/02_code_duplication/nodejs/.cpd.yml rename to resources/07_non_func/02_code_duplication/nodejs/.cpd.yml diff --git a/exercises/05_code_quality/02_code_duplication/nodejs/modules/index.js b/resources/07_non_func/02_code_duplication/nodejs/modules/index.js similarity index 100% rename from exercises/05_code_quality/02_code_duplication/nodejs/modules/index.js rename to resources/07_non_func/02_code_duplication/nodejs/modules/index.js diff --git a/exercises/05_code_quality/02_code_duplication/nodejs/modules/test.js b/resources/07_non_func/02_code_duplication/nodejs/modules/test.js similarity index 100% rename from exercises/05_code_quality/02_code_duplication/nodejs/modules/test.js rename to resources/07_non_func/02_code_duplication/nodejs/modules/test.js diff --git a/exercises/05_code_quality/05_unit/Java/Lister.java b/resources/07_non_func/03_dependencies/java/Lister.java similarity index 100% rename from exercises/05_code_quality/05_unit/Java/Lister.java rename to resources/07_non_func/03_dependencies/java/Lister.java diff --git a/exercises/05_code_quality/03_dependencies/java/README.md b/resources/07_non_func/03_dependencies/java/README.md similarity index 100% rename from exercises/05_code_quality/03_dependencies/java/README.md rename to resources/07_non_func/03_dependencies/java/README.md diff --git a/exercises/05_code_quality/03_dependencies/nodejs/README.md b/resources/07_non_func/03_dependencies/nodejs/README.md similarity index 100% rename from exercises/05_code_quality/03_dependencies/nodejs/README.md rename to resources/07_non_func/03_dependencies/nodejs/README.md diff --git a/exercises/05_code_quality/04_profiling/nodejs/README.md b/resources/07_non_func/04_profiling/nodejs/README.md similarity index 100% rename from exercises/05_code_quality/04_profiling/nodejs/README.md rename to resources/07_non_func/04_profiling/nodejs/README.md diff --git a/exercises/08_ci/arduino/README.md b/resources/08_ci/arduino/README.md similarity index 100% rename from exercises/08_ci/arduino/README.md rename to resources/08_ci/arduino/README.md diff --git a/exercises/08_ci/jenkins.md b/resources/08_ci/jenkins.md similarity index 100% rename from exercises/08_ci/jenkins.md rename to resources/08_ci/jenkins.md diff --git a/exercises/08_ci/node/.eslintignore b/resources/08_ci/node/.eslintignore similarity index 100% rename from exercises/08_ci/node/.eslintignore rename to resources/08_ci/node/.eslintignore diff --git a/exercises/07_version_control/nodejs_pre_commit/.eslintrc.json b/resources/08_ci/node/.eslintrc.json similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/.eslintrc.json rename to resources/08_ci/node/.eslintrc.json diff --git a/exercises/08_ci/node/.gitignore b/resources/08_ci/node/.gitignore similarity index 100% rename from exercises/08_ci/node/.gitignore rename to resources/08_ci/node/.gitignore diff --git a/exercises/08_ci/node/.gitlab-ci.yml b/resources/08_ci/node/.gitlab-ci.yml similarity index 100% rename from exercises/08_ci/node/.gitlab-ci.yml rename to resources/08_ci/node/.gitlab-ci.yml diff --git a/exercises/07_version_control/nodejs_pre_commit/.istanbul.yml b/resources/08_ci/node/.istanbul.yml similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/.istanbul.yml rename to resources/08_ci/node/.istanbul.yml diff --git a/exercises/08_ci/node/README.md b/resources/08_ci/node/README.md similarity index 100% rename from exercises/08_ci/node/README.md rename to resources/08_ci/node/README.md diff --git a/exercises/07_version_control/nodejs_pre_commit/modules/notes.js b/resources/08_ci/node/modules/notes.js similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/modules/notes.js rename to resources/08_ci/node/modules/notes.js diff --git a/exercises/08_ci/node/package.json b/resources/08_ci/node/package.json similarity index 100% rename from exercises/08_ci/node/package.json rename to resources/08_ci/node/package.json diff --git a/exercises/08_ci/node/spec/jasmine.json b/resources/08_ci/node/spec/jasmine.json similarity index 100% rename from exercises/08_ci/node/spec/jasmine.json rename to resources/08_ci/node/spec/jasmine.json diff --git a/exercises/07_version_control/nodejs_pre_commit/spec/notes-spec.js b/resources/08_ci/node/spec/notes-spec.js similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/spec/notes-spec.js rename to resources/08_ci/node/spec/notes-spec.js diff --git a/exercises/07_version_control/nodejs_pre_commit/spec/testRunner.js b/resources/08_ci/node/spec/testRunner.js similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/spec/testRunner.js rename to resources/08_ci/node/spec/testRunner.js diff --git a/exercises/09_acceptance/01_behaviour_driven_development/README.md b/resources/09_acceptance/01_behaviour_driven_development/README.md similarity index 100% rename from exercises/09_acceptance/01_behaviour_driven_development/README.md rename to resources/09_acceptance/01_behaviour_driven_development/README.md diff --git a/exercises/09_acceptance/01_behaviour_driven_development/commandLine/docGenerator.js b/resources/09_acceptance/01_behaviour_driven_development/commandLine/docGenerator.js similarity index 100% rename from exercises/09_acceptance/01_behaviour_driven_development/commandLine/docGenerator.js rename to resources/09_acceptance/01_behaviour_driven_development/commandLine/docGenerator.js diff --git a/exercises/09_acceptance/01_behaviour_driven_development/commandLine/features/simple.feature b/resources/09_acceptance/01_behaviour_driven_development/commandLine/features/simple.feature similarity index 100% rename from exercises/09_acceptance/01_behaviour_driven_development/commandLine/features/simple.feature rename to resources/09_acceptance/01_behaviour_driven_development/commandLine/features/simple.feature diff --git a/exercises/09_acceptance/01_behaviour_driven_development/website/docGenerator.js b/resources/09_acceptance/01_behaviour_driven_development/website/docGenerator.js similarity index 100% rename from exercises/09_acceptance/01_behaviour_driven_development/website/docGenerator.js rename to resources/09_acceptance/01_behaviour_driven_development/website/docGenerator.js diff --git a/exercises/09_acceptance/01_behaviour_driven_development/website/features/findFreeAppointmentSlot.feature b/resources/09_acceptance/01_behaviour_driven_development/website/features/findFreeAppointmentSlot.feature similarity index 100% rename from exercises/09_acceptance/01_behaviour_driven_development/website/features/findFreeAppointmentSlot.feature rename to resources/09_acceptance/01_behaviour_driven_development/website/features/findFreeAppointmentSlot.feature diff --git a/exercises/09_acceptance/02_executable_specifications/android/README.md b/resources/09_acceptance/02_executable_specifications/android/README.md similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/android/README.md rename to resources/09_acceptance/02_executable_specifications/android/README.md diff --git a/exercises/09_acceptance/02_executable_specifications/ios/README.md b/resources/09_acceptance/02_executable_specifications/ios/README.md similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/ios/README.md rename to resources/09_acceptance/02_executable_specifications/ios/README.md diff --git a/exercises/09_acceptance/02_executable_specifications/simple/features/simple.feature b/resources/09_acceptance/02_executable_specifications/simple/features/simple.feature similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/simple/features/simple.feature rename to resources/09_acceptance/02_executable_specifications/simple/features/simple.feature diff --git a/exercises/09_acceptance/02_executable_specifications/simple/features/step_definitions/simple_definitions.js b/resources/09_acceptance/02_executable_specifications/simple/features/step_definitions/simple_definitions.js similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/simple/features/step_definitions/simple_definitions.js rename to resources/09_acceptance/02_executable_specifications/simple/features/step_definitions/simple_definitions.js diff --git a/exercises/09_acceptance/02_executable_specifications/testingAPIs/README.md b/resources/09_acceptance/02_executable_specifications/testingAPIs/README.md similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/testingAPIs/README.md rename to resources/09_acceptance/02_executable_specifications/testingAPIs/README.md diff --git a/exercises/09_acceptance/02_executable_specifications/website/README.md b/resources/09_acceptance/02_executable_specifications/website/README.md similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/website/README.md rename to resources/09_acceptance/02_executable_specifications/website/README.md diff --git a/exercises/09_acceptance/02_executable_specifications/website/features/documentation.feature b/resources/09_acceptance/02_executable_specifications/website/features/documentation.feature similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/website/features/documentation.feature rename to resources/09_acceptance/02_executable_specifications/website/features/documentation.feature diff --git a/exercises/09_acceptance/02_executable_specifications/website/features/step_definitions/browser_steps.js b/resources/09_acceptance/02_executable_specifications/website/features/step_definitions/browser_steps.js similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/website/features/step_definitions/browser_steps.js rename to resources/09_acceptance/02_executable_specifications/website/features/step_definitions/browser_steps.js diff --git a/exercises/09_acceptance/02_executable_specifications/website/features/step_definitions/hooks.js b/resources/09_acceptance/02_executable_specifications/website/features/step_definitions/hooks.js similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/website/features/step_definitions/hooks.js rename to resources/09_acceptance/02_executable_specifications/website/features/step_definitions/hooks.js diff --git a/exercises/09_acceptance/02_executable_specifications/website/features/support/world.js b/resources/09_acceptance/02_executable_specifications/website/features/support/world.js similarity index 100% rename from exercises/09_acceptance/02_executable_specifications/website/features/support/world.js rename to resources/09_acceptance/02_executable_specifications/website/features/support/world.js diff --git a/exercises/09_acceptance/03_acceptance_testing/microcontrollers/README.md b/resources/09_acceptance/03_acceptance_testing/microcontrollers/README.md similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/microcontrollers/README.md rename to resources/09_acceptance/03_acceptance_testing/microcontrollers/README.md diff --git a/exercises/09_acceptance/03_acceptance_testing/testingAPIs/README.md b/resources/09_acceptance/03_acceptance_testing/testingAPIs/README.md similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/testingAPIs/README.md rename to resources/09_acceptance/03_acceptance_testing/testingAPIs/README.md diff --git a/exercises/09_acceptance/03_acceptance_testing/testingAPIs/index.js b/resources/09_acceptance/03_acceptance_testing/testingAPIs/index.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/testingAPIs/index.js rename to resources/09_acceptance/03_acceptance_testing/testingAPIs/index.js diff --git a/exercises/09_acceptance/03_acceptance_testing/testingAPIs/lists.js b/resources/09_acceptance/03_acceptance_testing/testingAPIs/lists.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/testingAPIs/lists.js rename to resources/09_acceptance/03_acceptance_testing/testingAPIs/lists.js diff --git a/exercises/09_acceptance/03_acceptance_testing/testingAPIs/package.json b/resources/09_acceptance/03_acceptance_testing/testingAPIs/package.json similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/testingAPIs/package.json rename to resources/09_acceptance/03_acceptance_testing/testingAPIs/package.json diff --git a/exercises/09_acceptance/03_acceptance_testing/testingAPIs/todo-spec.js b/resources/09_acceptance/03_acceptance_testing/testingAPIs/todo-spec.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/testingAPIs/todo-spec.js rename to resources/09_acceptance/03_acceptance_testing/testingAPIs/todo-spec.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/README.md b/resources/09_acceptance/03_acceptance_testing/website/README.md similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/README.md rename to resources/09_acceptance/03_acceptance_testing/website/README.md diff --git a/exercises/09_acceptance/03_acceptance_testing/website/basic-math-spec.js b/resources/09_acceptance/03_acceptance_testing/website/basic-math-spec.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/basic-math-spec.js rename to resources/09_acceptance/03_acceptance_testing/website/basic-math-spec.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/basic-math.html b/resources/09_acceptance/03_acceptance_testing/website/basic-math.html similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/basic-math.html rename to resources/09_acceptance/03_acceptance_testing/website/basic-math.html diff --git a/exercises/09_acceptance/03_acceptance_testing/website/conditionals-booleans-spec.js b/resources/09_acceptance/03_acceptance_testing/website/conditionals-booleans-spec.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/conditionals-booleans-spec.js rename to resources/09_acceptance/03_acceptance_testing/website/conditionals-booleans-spec.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/conditionals-booleans.html b/resources/09_acceptance/03_acceptance_testing/website/conditionals-booleans.html similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/conditionals-booleans.html rename to resources/09_acceptance/03_acceptance_testing/website/conditionals-booleans.html diff --git a/exercises/09_acceptance/03_acceptance_testing/website/css/styles.css b/resources/09_acceptance/03_acceptance_testing/website/css/styles.css similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/css/styles.css rename to resources/09_acceptance/03_acceptance_testing/website/css/styles.css diff --git a/exercises/09_acceptance/03_acceptance_testing/website/js/contact.js b/resources/09_acceptance/03_acceptance_testing/website/js/contact.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/js/contact.js rename to resources/09_acceptance/03_acceptance_testing/website/js/contact.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/js/notes.js b/resources/09_acceptance/03_acceptance_testing/website/js/notes.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/js/notes.js rename to resources/09_acceptance/03_acceptance_testing/website/js/notes.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/js/shopping.js b/resources/09_acceptance/03_acceptance_testing/website/js/shopping.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/js/shopping.js rename to resources/09_acceptance/03_acceptance_testing/website/js/shopping.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/notes-spec.js b/resources/09_acceptance/03_acceptance_testing/website/notes-spec.js similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/notes-spec.js rename to resources/09_acceptance/03_acceptance_testing/website/notes-spec.js diff --git a/exercises/09_acceptance/03_acceptance_testing/website/notes.html b/resources/09_acceptance/03_acceptance_testing/website/notes.html similarity index 100% rename from exercises/09_acceptance/03_acceptance_testing/website/notes.html rename to resources/09_acceptance/03_acceptance_testing/website/notes.html diff --git a/exercises/10_continuous_delivery/FTP.md b/resources/10_continuous_delivery/FTP.md similarity index 100% rename from exercises/10_continuous_delivery/FTP.md rename to resources/10_continuous_delivery/FTP.md diff --git a/exercises/10_continuous_delivery/SSH.md b/resources/10_continuous_delivery/SSH.md similarity index 100% rename from exercises/10_continuous_delivery/SSH.md rename to resources/10_continuous_delivery/SSH.md diff --git a/exercises/10_continuous_delivery/SSHFS.md b/resources/10_continuous_delivery/SSHFS.md similarity index 100% rename from exercises/10_continuous_delivery/SSHFS.md rename to resources/10_continuous_delivery/SSHFS.md diff --git a/exercises/10_continuous_delivery/env_var.md b/resources/10_continuous_delivery/env_var.md similarity index 100% rename from exercises/10_continuous_delivery/env_var.md rename to resources/10_continuous_delivery/env_var.md diff --git a/exercises/10_continuous_delivery/paths.md b/resources/10_continuous_delivery/paths.md similarity index 100% rename from exercises/10_continuous_delivery/paths.md rename to resources/10_continuous_delivery/paths.md diff --git a/exercises/10_continuous_delivery/rsync.md b/resources/10_continuous_delivery/rsync.md similarity index 100% rename from exercises/10_continuous_delivery/rsync.md rename to resources/10_continuous_delivery/rsync.md diff --git a/exercises/10_continuous_delivery/shell_scripts.md b/resources/10_continuous_delivery/shell_scripts.md similarity index 100% rename from exercises/10_continuous_delivery/shell_scripts.md rename to resources/10_continuous_delivery/shell_scripts.md diff --git a/exercises/07_version_control/README.md b/resources/11_version_control/README.md similarity index 100% rename from exercises/07_version_control/README.md rename to resources/11_version_control/README.md diff --git a/exercises/07_version_control/nodejs_pre_commit/.eslintignore b/resources/11_version_control/nodejs_pre_commit/.eslintignore similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/.eslintignore rename to resources/11_version_control/nodejs_pre_commit/.eslintignore diff --git a/exercises/08_ci/node/.eslintrc.json b/resources/11_version_control/nodejs_pre_commit/.eslintrc.json similarity index 100% rename from exercises/08_ci/node/.eslintrc.json rename to resources/11_version_control/nodejs_pre_commit/.eslintrc.json diff --git a/exercises/07_version_control/nodejs_pre_commit/.gitignore b/resources/11_version_control/nodejs_pre_commit/.gitignore similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/.gitignore rename to resources/11_version_control/nodejs_pre_commit/.gitignore diff --git a/exercises/08_ci/node/.istanbul.yml b/resources/11_version_control/nodejs_pre_commit/.istanbul.yml similarity index 100% rename from exercises/08_ci/node/.istanbul.yml rename to resources/11_version_control/nodejs_pre_commit/.istanbul.yml diff --git a/exercises/07_version_control/nodejs_pre_commit/README.md b/resources/11_version_control/nodejs_pre_commit/README.md similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/README.md rename to resources/11_version_control/nodejs_pre_commit/README.md diff --git a/exercises/08_ci/node/modules/notes.js b/resources/11_version_control/nodejs_pre_commit/modules/notes.js similarity index 100% rename from exercises/08_ci/node/modules/notes.js rename to resources/11_version_control/nodejs_pre_commit/modules/notes.js diff --git a/exercises/07_version_control/nodejs_pre_commit/modules/request.js b/resources/11_version_control/nodejs_pre_commit/modules/request.js similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/modules/request.js rename to resources/11_version_control/nodejs_pre_commit/modules/request.js diff --git a/exercises/07_version_control/nodejs_pre_commit/package.json b/resources/11_version_control/nodejs_pre_commit/package.json similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/package.json rename to resources/11_version_control/nodejs_pre_commit/package.json diff --git a/exercises/07_version_control/nodejs_pre_commit/spec/jasmine.json b/resources/11_version_control/nodejs_pre_commit/spec/jasmine.json similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/spec/jasmine.json rename to resources/11_version_control/nodejs_pre_commit/spec/jasmine.json diff --git a/exercises/08_ci/node/spec/notes-spec.js b/resources/11_version_control/nodejs_pre_commit/spec/notes-spec.js similarity index 100% rename from exercises/08_ci/node/spec/notes-spec.js rename to resources/11_version_control/nodejs_pre_commit/spec/notes-spec.js diff --git a/exercises/07_version_control/nodejs_pre_commit/spec/request-spec.js b/resources/11_version_control/nodejs_pre_commit/spec/request-spec.js similarity index 100% rename from exercises/07_version_control/nodejs_pre_commit/spec/request-spec.js rename to resources/11_version_control/nodejs_pre_commit/spec/request-spec.js diff --git a/exercises/08_ci/node/spec/testRunner.js b/resources/11_version_control/nodejs_pre_commit/spec/testRunner.js similarity index 100% rename from exercises/08_ci/node/spec/testRunner.js rename to resources/11_version_control/nodejs_pre_commit/spec/testRunner.js diff --git a/teams/README.md b/teams/README.md index b112594..e3846a3 100644 --- a/teams/README.md +++ b/teams/README.md @@ -8,7 +8,7 @@ You have been placed in multi-skilled teams and will be working in these through Tuesday 09:00-11:00 and Wednesday 11:00-13:00 1. Thomas Bassett -2. Daniel Steven Beglin +2. Marius Gamulea 3. Nikhil Dassor 4. Tahir Saddique Gulzed 5. Jabor Mubarak J M Al-Ali @@ -56,7 +56,8 @@ Tuesday 09:00-11:00 and Wednesday 11:00-13:00 5. James Mensah 6. Ross Patrick Aneurin Miller 7. Kate Sturmey -8. Gongzhi Wang +8. Gongzhi Wang +9. Mfoniso Jackson ## 🦊 Team Fox @@ -123,6 +124,7 @@ Tuesday 11:00-13:00 and Friday 09:00-11:00 6. Jessica Pearson 7. Erin Rai 8. Jaewoong Yu +9. Daniel Steven Beglin ## 🐰 Team Rabbit