| commit | author | age | ||
| 007b55 | 1 | # The Non Functionals Strike back |
| D | 2 | > In this exercise we explore the non-functional side of testing. |
| 43f2f2 | 3 | _____ |
| D | 4 | |
| 5 | ## Learning Outcomes | |
| 6 | As a learner you will be able to | |
| 007b55 | 7 | - Create additional Jenkins stages to scan for security vulnerabilities in the Apps |
| D | 8 | - Assess test quiality by producing coveage reports as part of a build |
| 9 | - Improve code readability with linting | |
| 10 | - Do some light performance testing to monitor throughput of APIs | |
| 43f2f2 | 11 | |
| D | 12 | ## Tools and Frameworks |
| 007b55 | 13 | > Below is a collection of the frameworks that will be used in this lab |
| 43f2f2 | 14 | |
| 007b55 | 15 | 1. [eslint](https://eslint.org/) - ESLint is an open source JavaScript linting utility originally created by Nicholas C. Zakas in June 2013. Code linting is a type of static analysis that is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines. There are code linters for most programming languages, and compilers sometimes incorporate linting into the compilation process. |
| 43f2f2 | 16 | |
| D | 17 | ## Big Picture |
| 18 | This exercise begins cluster containing blah blah | |
| 19 | ||
| 20 | _____ | |
| 21 | ||
| 22 | ## 10,000 Ft View | |
| 007b55 | 23 | > This lesson will use the Exerisise 4's Zap Slave and Arachni scanner to improve the pipeline. Linting will be included in the build and code coverage too. |
| 43f2f2 | 24 | |
| 007b55 | 25 | 2. Add a parallel stage after the e2e tests on the front end to run OWASP Zap and Arachni against the deployed apps. |
| 43f2f2 | 26 | |
| 007b55 | 27 | 2. Add Code Coverage reporing to the build for gaining greater insight into test improvements. |
| D | 28 | |
| 29 | 2. Add `npm run lint:ci` to the Frontend and report the result using the Checkstyle Plugin in Jenkins. | |
| 30 | ||
| 31 | 2. Create a new Jenkins job to run some light performance testing against the API layer using the perf tests tasks. | |
| 43f2f2 | 32 | |
| D | 33 | ## Step by Step Instructions |
| 007b55 | 34 | > This is a well structured guide with references to exact filenames and indications as to what should be done. |
| 43f2f2 | 35 | |
| 007b55 | 36 | ### Part 1 - Add Security scanning to the pipeline |
| dc377a | 37 | > _In this exercise the first of our non-functional testing is explored in the form of some security scanning. We will add the scans to our Jenkinsfile and have them run as new stages_ |
| 43f2f2 | 38 | |
| dc377a | 39 | 2. Open the `todolist-fe` application's `Jenkinsfile` in your favourite editor. The file is stored in the root of the project. |
| D | 40 | |
| 41 | 2. The file is layed out with a collection of stages that correspond to each part of our build as seen below. We will create a new stage to execute in parallel. | |
| cd34aa | 42 |  |
| dc377a | 43 | |
| D | 44 | 2. Create a new Parallel Stage called `security scanning` underneath the `stage("e2e test") { }` section as shown below. The contents of the `e2e test` has been removed for simplicity. |
| 45 | ```groovy | |
| 46 | stage("e2e test") { | |
| 47 | // ... stuff in here .... | |
| 48 | } | |
| 49 | stage("security scanning") { | |
| 50 | parallel { | |
| 51 | stage('OWASP Scan') { | |
| 52 | ||
| 53 | } | |
| 54 | stage('Arachni Scan') { | |
| 55 | ||
| 56 | } | |
| 57 | } | |
| 58 | } | |
| 43f2f2 | 59 | ``` |
| dc377a | 60 | |
| D | 61 | 2. Let's start filling out the configuration for the OWASP Zap scan first. We will set the label to our slave created in previous exercise and a when condition of the mater or develop branch. |
| 62 | ```groovy | |
| 63 | stage('OWASP Scan') { | |
| 64 | agent { | |
| 65 | node { | |
| 66 | label "jenkins-slave-zap" | |
| 67 | } | |
| 68 | } | |
| 69 | when { | |
| 70 | expression { GIT_BRANCH ==~ /(.*master|.*develop)/ } | |
| 71 | } | |
| 72 | } | |
| 43f2f2 | 73 | ``` |
| dc377a | 74 | |
| D | 75 | 2. A command to run the tool by passing in the URL of the app we're going to test. |
| 76 | ```groovy | |
| 77 | stage('OWASP Scan') { | |
| 78 | agent { | |
| 79 | node { | |
| 80 | label "jenkins-slave-zap" | |
| 81 | } | |
| 82 | } | |
| 83 | when { | |
| 84 | expression { GIT_BRANCH ==~ /(.*master|.*develop)/ } | |
| 85 | } | |
| 86 | steps { | |
| 87 | sh ''' | |
| 88 | /zap/zap-baseline.py -r index.html -t ${E2E_TEST_ROUTE} | |
| 89 | ''' | |
| 90 | } | |
| 91 | } | |
| 92 | ``` | |
| 93 | ||
| 94 | 2. Finally add the reporting for Jenkins in `post` hook of our Declarative Pipeline. This is to report the findings of the scan in Jenkins as a HTML report. | |
| 95 | ```groovy | |
| 96 | stage('OWASP Scan') { | |
| 97 | agent { | |
| 98 | node { | |
| 99 | label "jenkins-slave-zap" | |
| 100 | } | |
| 101 | } | |
| 102 | when { | |
| 103 | expression { GIT_BRANCH ==~ /(.*master|.*develop)/ } | |
| 104 | } | |
| 105 | steps { | |
| 106 | sh ''' | |
| da9923 | 107 | /zap/zap-baseline.py -r index.html -t http://${E2E_TEST_ROUTE} |
| dc377a | 108 | exit $? |
| D | 109 | ''' |
| 110 | } | |
| 111 | post { | |
| 112 | always { | |
| 113 | // publish html | |
| 114 | publishHTML target: [ | |
| 115 | allowMissing: false, | |
| 116 | alwaysLinkToLastBuild: false, | |
| 117 | keepAll: true, | |
| 118 | reportDir: '/zap/wrk', | |
| 119 | reportFiles: 'index.html', | |
| 120 | reportName: 'Zap Branniscan' | |
| 121 | ] | |
| 122 | } | |
| 123 | } | |
| 124 | } | |
| 125 | ``` | |
| 126 | ||
| 127 | 2. Let's add our Arachni Scann to the second part of the parallel block. The main difference between these sections is Jenkins will report an XML report too for failing the build accordingly. Below is the snippet for the Arachni scanning. | |
| 128 | ```groovy | |
| 129 | stage('Arachni Scan') { | |
| 130 | agent { | |
| 131 | node { | |
| 132 | label "jenkins-slave-arachni" | |
| 133 | } | |
| 134 | } | |
| 135 | when { | |
| 136 | expression { GIT_BRANCH ==~ /(.*master|.*develop)/ } | |
| 137 | } | |
| 138 | steps { | |
| 139 | sh ''' | |
| da9923 | 140 | /arachni/bin/arachni http://${E2E_TEST_ROUTE} --report-save-path=arachni-report.afr |
| dc377a | 141 | /arachni/bin/arachni_reporter arachni-report.afr --reporter=xunit:outfile=report.xml --reporter=html:outfile=web-report.zip |
| D | 142 | unzip web-report.zip -d arachni-web-report |
| 143 | ''' | |
| 144 | } | |
| 145 | post { | |
| 146 | always { | |
| 147 | junit 'report.xml' | |
| 148 | publishHTML target: [ | |
| 149 | allowMissing: false, | |
| 150 | alwaysLinkToLastBuild: false, | |
| 151 | keepAll: true, | |
| 152 | reportDir: 'arachni-web-report', | |
| 153 | reportFiles: 'index.html', | |
| 154 | reportName: 'Arachni Web Crawl' | |
| 155 | ] | |
| 156 | } | |
| 157 | } | |
| 158 | } | |
| 159 | ``` | |
| 160 | ||
| cd34aa | 161 | 2. With this config in place run a build on Jenkins. Once the Jobs have completed; navigate to the Jobs status and see the scores. You can find the graphs and test reports on overview of the Job. Explore the results! |
| D | 162 |  |
| 163 |  | |
| 164 | ||
| 165 | <p class="tip"> | |
| 166 | NOTE - your build may have failed but the reports should still be generated! | |
| 167 | </p> | |
| 43f2f2 | 168 | |
| 007b55 | 169 | ### Part 2 - Add Code Coverage & Linting to the pipeline |
| 43f2f2 | 170 | > _prefix of exercise and why we're doing it_ |
| D | 171 | |
| 172 | 3. Do other things | |
| 173 | ||
| 174 | _____ | |
| 175 | ||
| 176 | ## Extension Tasks | |
| 177 | > _Ideas for go-getters. Advanced topic for doers to get on with if they finish early. These will usually not have a solution and are provided for additional scope._ | |
| 178 | ||
| 007b55 | 179 | - Add Black Duck or other package scanning tooling for our NodeJS app |
| D | 180 | - Add Container Vulnerability scanning tooling to the pipeline |
| dc377a | 181 | - Add security scanning tools to the API |
| 43f2f2 | 182 | |
| D | 183 | ## Additional Reading |
| 184 | > List of links or other reading that might be of use / reference for the exercise | |
| 185 | ||
| 186 | ## Slide links | |
| 187 | > link back to the deck for the supporting material | |
