Team Members:
- Ayush Gupta - [email protected]
- Nishtha Garg - [email protected]
- Shivam Gulati - [email protected]
We have used Jenkins to configure the build server. Alongwith Jenkins, we have used Tomcat, Git for Source Code Management and NPM as a package manager.
Additions tools used: eslint, jsinspect, istanbul, cobertura, checkstyle, esprima
We used the MIT licensed Climbing-Grade project which is forked at
https://github.com/shivamgulati1991/climbing-grade
- Create a new job. Give it a name. Choose Freestyle Project.
- For configuration of Job Source Code Management-> select Git under Source Code Management-> Enter your project's Git Repository URL.
- Under Build Environment-> select "Provide Node & npm bin/ folder to PATH"-> choose the NodeJS installation.
- Additionally, you can also setup multiple branches for the same job.
- Click Save.
- Test run a build - Go to Jobs and click "Build Now".
We used Istanbul code coverage with tests and Cobertura Jenkins plugin to display the report.
- Go to Manage Jenkins->Manage Plugin->Install Cobertura plugin.
- Go to your Job -> Configure-> Build-> Execute shell, write this code.
rm -rf node_modules
npm install
npm test
Calling npm test calls the test suit, generates the report using istanbul and writes it into cobertura-coverage.xml. This report is fed to Cobertura Jenkins plugin for display. We used '.istanbul.yml' file for it to generate cobertura-coverage.xml file
- In Post-build section, select Publish Cobertura Coverage Report and give this report path which is generated by istanbul
**/coverage/cobertura-coverage.xml
- Click Save.
- Build the job
Advanced Testing: Implement one of the following advanced testing techniques: test priorization, test case generation, fuzzing, or flaky test quarantine.
For this step, we implemented the constraint test case generation method similar to the coursework workshop and homeworks. We noticed that our coverage increased as per this implementation.
- In our main.js file, we wrote the code for test case generation and added the contraints.
- This file was fed to instanbul for code coverage and consumed by Cobertura Jenkins plugin similar to the step one.
- In Jenking job -> Build -> Execute shell
rm -rf node_modules
npm install
node main.js
npm run customtest
- 'node main.js' runs the test case generation and generates 'test.js' file which is run as per 'npm run customtest'. The 'package.json' file has the reference for the same. Istanbul generates the Cobertura coverage report and Cobertura plugin uses the same to display in Jenkins.
Basic Analysis: The ability to run an existing static analysis tool on the source code (e.g. FindBugs, PMD, CheckStyle, NCover, Lint, etc.), process its results, and report its findings.
We used eslint for basic analysis on our source code. eslint performs static analysis and outputs its results. We also used CheckStyle Jenkins plugin to display the same in Jenkins.
- Go to Manage Jenkins->Manage Plugin->Install CheckStyle plugin.
- Go to your Job -> Configure-> Build-> Execute shell, write this code.
rm -rf node_modules
npm install
npm test
npm run lint || :
- In your configure -> Post-build section, select Publish CheckStyle Analysis Results and leave the path blank so it takes the default on its own.
- Build your job. While building eslint will perform static analysis on the code and output the results and warnings to Jenkins.
As taught in complexity class workshop, we used the same approach and extended the code to count the conditions and report the output.
As taught in complexity class workshop, we used the same approach and extended the code to count the conditions and report the output. We decided 30 lines as a threshold to detect long methods for this, and any method above that results in the output with the lines of code it contains. We added a AWS token to our code file to detect the same.
Since AWS and Digital Ocean and the primary providers we have used so far, we used regular expressions to generate the pattern for security token for both of them. We wrote the script detectToken.js which checks for the same and reports the output if there is a token present in the code.
- The conditions count and long method detection are run from the file 'analysis.js' and token detection is present in 'detectToken.js'.
- Go to Jenkins job -> Configure -> Build, add the below code to the existing steps.
node analysis.js
node detectToken.js
All above 3 metrics are shown in this screencast.
We used the jsinspect library to detect the code duplication. The dependency for the same was added to 'package.json' file installs the packages with 'npm install' during the build. The project's repository is
https://github.com/danielstjules/jsinspect
For adding it to build process,
- Go to Job-> Configure -> Build section.
- We add 'jsinspect' command to run the code matching algorithm to find duplicates.
rm -rf node_modules
npm install
jsinspect -t 30 ./
npm test
npm run lint || :
Screencast for finding duplicate code
Gates: Using hooks or post-build scripts, have the ability to reject a commit if it fails a minimum testing criteria (e.g. failed test case, or less than 50% statement coverage) and analysis criteria (e.g. cannot commits that generate a particular FindBugs rule, such as "Method concatenates strings using + in a loop").
We wrote a git hook which on commit, performs testing and analysis on the code.
- If the test cases fail, the commit is rejected.
- For the analysis, we used the eslint rules to especially check for 'no-unreachable' code area, basically if the code has unreachable code part, it is detected and the commit is rejected. All rules are defined in file '.eslintrc.js'
- If both testing criteria and analysis criteria does not result in any error, the commit is successful.
Screencast for rejecting commit with failing test case
Screencast for rejecting commit with analysis
Screencast for a successful commit after both testing and analysis pass
Sources: