Unit Testing in Jenkins

Jason Taylor
A free video tutorial from Jason Taylor
Lead Software Engineer, Dev Trainer (19 courses,50k reviews)
4.4 instructor rating • 19 courses • 425,350 students

Lecture description

Reviewing the Unit test results for our time tracker project within the terminal output as well as within the individual modules for our Maven build. Also will causing a test to fail in order to observe what that does to our results trend.

Learn more from the full course

Jenkins 2 Bootcamp: Fully Automate Builds to Deployment 2020

An introduction to the Jenkins build server using continuous integration and deployment techniques -- all step by step.

08:43:20 of on-demand video • Updated May 2020

  • Install Jenkins CI server on Windows
  • Install and configure several tools commonly used with Jenkins
  • Understand the basics of continuous inspection, continuous integration, and continuous deployment
  • Use Jenkins effectively to build, test, analyze and deploy Java projects
  • Apply the techniques and experience to implement Jenkins and/or a continuous integration system
English Welcome, in this lesson, we're going to review the unit test results for the time tracker project. We are currently on our project status page. Click on the build status for the most recent build to check out the console output. So far we've seen the start and the end of the Maven builds, but near the middle is where the unit testing actually happens. Maven uses the surefire plug in to run any unit tests defined in the project, provided they're located in the correct location. To quickly jump to that spot in the build, do a search for "surefire". That should take us to the start of the unit testing phase of the maven build. From here we can scroll through the unit testing results, which will be a lot of initialization for the Spring Framework. And you might even catch a line giving a summary of a particular test run. At the end of this testing phase there will be a summary for the entire test phase. The surefire plugin will execute for all the submodules that make up this project, but only the submodules that contain unit tests will show any results. Great. Let's jump back down to the project status page. Once there let's peek in to the workspace to look for the report files generated during the testing phase. Once in the workspace the only module that ran in a unit test is the core module so go into that folder. From here Maven places all the build artifacts, including reports, into the target folder. Let's go into that folder. Within the target folder, since the surefire plugin is responsible for running the unit tests, look for a folder named "surefire-reports". Great, dive into that folder. Here's where the reports are located. And we have two flavors of the unit tests result reports; plain text and XML. Of course plain text is a lot easier for people to review. If you click on the files or use the view link in Chrome, you'll need to use the back button feature to return to Jenkins. The XML versions of the reports are for programs like Jenkins to easily consume and integrate. Great, let's have a look at that integration now. Now let's return to the project's status page. From here we could click on either test results. We will land on the last build's test results. The test results will list the results by Maven module, which in this case there's only one module, the time tracker core module, that contains any unit tests. We have three tests in this module, with none failing right now. Click into the module. Within the core module we have a summary at the top, including how long the test took and overall success or failure rate. Under all tests we have the test stats by Java package. Again, only one package. Click into that package. From here we have each class in the Java package listed with a number of failing passing and total unit test per class. If you click into a class we have a listing of unit test methods executed, and their status and duration. We have gone really deep into a specific module of a specific build. You can see that reflected in the breadcrumb navigation. Let's jump back to the project's status page. Now let's change one of the tests to make it fail and see what that looks like. Open up or return to your copy of the time tracker repository on GitHub. Then drill down into the core module folder, then into the "src" folder. Then follow the "test/java" folder path down to the core package folder. We now have our JUnit test classes. Let's edit the TrackerTest.java file. Click on the file, and once open click on the edit button. We're going to make a very simple but effective change. Go to the last "assert" statement and change the operator from greater than to less than. Of course this will return false, which will cause the assert statement to fail. Save the change to this file by making the commit at the bottom of the page Once done, return to our Jenkins page. Click "Build Now" to do a build with our new change included. Once the build has completed the new build has a yellow status, which normally means the build was technically successful but had some issues with unit testing or too poor quality. Also, you might need to refresh your web browser to see the latest information on the project's status page. The project's status page now has new information regarding the latest test result; it now reports one failure. Now dive into the reports and we see we have one failed build and markers that show the difference from the previous build. On the module status page and the project status page each test result report has changed slightly to show the increase in failed tests. OK, let's fix the build before moving forward. Return to the same file on GitHub and return the greater than sign to the assert statement Commit the change, and then re-build once back in Jenkins. Great, we should be back to a green build with the adjustments in our testing trend reports accordingly. In this lesson we looked at the unit test reports and trending graphs. We also caused one of the tests to fail and to see what that looks like. In the next lesson we will look at the code quality reports.