Unit Testing in Jenkins

A free video tutorial from Jason Taylor
Lead Software Engineer, Dev Trainer (19 courses,50k reviews)
4.4 instructor rating •
19 courses •
462,727 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 2020An 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.