diff --git a/09 Acceptance Testing.md b/09 Acceptance Testing.md index 563a4b4..1cea243 100644 --- a/09 Acceptance Testing.md +++ b/09 Acceptance Testing.md @@ -5,7 +5,18 @@ Each week you will be expected to complete a series of lab activities. You will You should refer to [this week's presentation](https://drive.google.com/open?id=1zShIZrqubjfqAf68On-mWzwmaU45shqY_2IVzzn5TJ0). -Before starting your next sprint, revisit each of the completed _user stories_ and define each of them using a _business-readable DSL_ such as Gherkin. There is an example in the `exercises` +Unlike in previous labs where each subteam carried out all the tasks, in this worksheet some of you will be carrying out part 1 and some of you part 2. Make sure you are clear as to which you should be doing. + +1. If your system is _directly used by the client_ (such as a website or smartphone app) you need to complete task 1 **User-Facing Acceptance Testing**. +2. If your system is _not_ directly accessed by the client (such as an API or embedded microcontroller) you need to complete task 2 **Backend Acceptance Testing** + +## 1 User-Facing Acceptance Testing + +Since the end users will directly interact with your part of the system you will need to implement your acceptance tests using Gherkin/Cucumber. + +### 1.1 Defining Scenarios + +Before starting your next sprint, revisit each of the completed _user stories_ and define each of them using a _business-readable DSL_ such as Gherkin. There is an example in the `exercises`. 1. Create a `features/` directory. 2. Create a file with a `.feature` extension for each user story. @@ -14,7 +25,7 @@ Before starting your next sprint, revisit each of the completed _user stories_ a 5. Under each scenario, list the steps required. 6. Finally you need to create a short _Javascript_ script called `testRunner.js` which will run the `gherkindoc` tool to generate your **documentation site**. -## Executable Specifications +### 1.2 Executable Specifications By now you should have a complete set of feature files that cover all the user stories you have developed so far. The next step is to convert these into _executable specifications_ using the **Cucumber** tool. This takes each _feature file_ and tries to run these against the software you are developing. @@ -27,21 +38,18 @@ There is some documentation plus sample code in the `exercises/09_acceptance/` d You can find some examples in the `exercises/09_acceptance/` directory. -## Acceptance Testing +## 2 Backend Acceptance Testing -At this stage you should have a full _suite_ of: +You will need to implement a suite of acceptance tests but, since you part of the system is not directly accessed by the end users, you won't need to define features and scenarios using Gherkin/Cucumber. -1. Gherkin feature files -2. A testrunner that converts these into executable specifications and runs them against your frontend. +There are a number of examples in the `exercises/09_acceptance/03_acceptance_testing/` directory and you will be able to find additional resources online. -Make sure that these are completed before continuing. +### 2.1 Microcontrollers and Acceptance Testing -The final step is to write the _feature files_ for the user stories you will be completing _in the next sprint_. +Acceptance testing can (and should) be carried out on an embedded system. The software should be flashed onto the controller and then tested: -1. Take each of the user stories and add a new `.feature` file for each. -2. Add the user story as a _feature_ to the files. -3. Define the success criteria by writing enough _scenarios_ to cover all eventualities. -4. You may need to tweak the _step definitions_. -5. Run the full test suite, the new scenarios should fail. +1. The test suite should subscribe to the apropriate MQTT channel. +2. It should supply an input to one or more of the pins. +3. The data coming from the MQTT channel should be compared to an expected value. -You are now ready to start the next sprint which will run all of next week. \ No newline at end of file +For this to work you will need a way to control the voltages being fed to the inputs. Probably the easiest way would be to use a second microcontroller (Arduino) and write a script to generate voltages at the ouput pins based on data sent through the USB/Serial cable.