The course is part of this learning path
Test-Driven Development (TDD) is a discipline that helps to create error-free, quality code, and drives productivity by reducing and eliminating errors as well as providing many other benefits.
This entry-level training course is designed to bring you quickly up to speed with the basic features and processes involved in performing Java based test-driven development using JUnit5. It covers the key principles and practices of test-driven development, which you can then utilize within your own software engineering projects.
In this course, you'll be guided through an end-to-end sample project in which we use test-driven development to build, test, and package a Java 11 based library that will provide an API to convert Bitcoins into foreign currency.
If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Understand the fundamentals of TDD and JUnit5
- Use TDD to build, test, and package a Java 11 based library
- Perform TDD by performing Red-Green-Refactor iterations
- Learn how to use TDD to build, test, and package a Java 11 based library
- Learn how to create unit tests using the JUnit5 testing framework
- Software developers interested in using TDD to build JDK11 based applications using Java
To get the most out of this course, you should have a basic understanding of JDK11 and the Java programming language, as well as software development and the software development life cycle (SDLC).
Welcome back, in this lesson, I'm going to introduce you to GitHub Actions as a method or service that we can use to do automated CI/CD builds for us. Now to do so, we're going to need a GitHub repo into which we'll upload our source code that we've written in the previous lessons.
So, in GitHub, under the Cloud Academy account, I'm going to click on the New repo button. And I'm going to call it demo_java_tdd. I'll copy that into the description, I'll make it public and I'll click the create repository. Next, I'm going to copy this block of commands here. I'll jump back into the Visual Studio code IDE. Now before I run those commands, I'll first set up a couple of things in terms of my credentials and who I am, et cetera. So, I'll run the following git config user.email, set it to be email@example.com. And then I'll set up user.name. And then also do git config credential.cache. And then I'll set the timeout to be 24 hours, but specified in seconds, like so.
Back to these commands. I shall now copy these and I'll paste them here to initialize our current project directory to be get enabled. Okay, I need to authenticate. And we're doing our first push successfully up into the repo. So, if I go back to our repository, refresh and we've got our README. So, clear the terminal.
Now, the next thing we wanna do is start uploading the source code. But before we do, I will create a .gitignore file. And I will enter the following settings to ensure that we only upload our source code and not any of the build out effects or libraries, et cetera. Back within the integrated terminal, I'll run git status. And then we can see we've got these untracked files and folders. So, I'll do a git add . to add everything. I'll do a git status again. Looks good, I'll do a git commit message, initial upload. I'll do a git push. And that will push all of our source code up into this new git repository.
Okay, that it's done. Go back to the repository, I'll now do a refresh. Okay, so we're looking good. Now, it's time to set up our first GitHub Actions build configuration. So, to do so, we click on Actions here. You have all of these template workflows that you can choose from. But I'll just click this link here because I wanna set up the workflow manually.
Okay, I'll change the name of the file to be build.yml and clear everything. And then what I'm going to do, is I'll jump to step five here. And then I'll copy the build config that I've already checked under the step five branch. Go back to our new repository, that's done. Now before I commit it, let's just quickly review it.
So, this is a special file that lives within the .github directory with our repo. And it's going to trigger on any push into this repo. It's going to run on top of an Ubuntu container. It is going to install JDK 1.11 and then it's going to run a Maven clean and package for us. It will lean copy the resultant jar files within the target directory, into our staging directory. And then finally, we run an upload to collect the artifact. Nice and simple. Okay, let's commit it.
Okay, that is done. If we now go back to the editor, I will do a git pull, pull the changes back down. I mean, at this stage we're ready to actually trigger a build. So, to do so, I'll just set a comment here in the README and then I'll run the command git commit_ m message updates, followed by a git push all in one.
Okay, so the code has been pushed up into the repo. If we swap over into the repo, we can see based on this visual indicator that an action has been kicked off. So, if we click into Actions, under results we click on Updates, click on Build under Jobs. And here we can see our build job steps. So, right now we're doing the Maven build. This is going to do a lot of downloading. It's got to do all of the third-party dependencies. It's now doing the tests, again it's got to download some stuff. We can see the builders just finished and now it's doing the artifact upload and everything is gone green, fantastic result.
So, our GitHub Action has been triggered based on our push. Stand on a CI/CD build of our Java, run our unit tests, and then uploaded the artifact. So, if we go back to summary, we can see here on artifacts, we indeed have a package. So, if we click on that, they'll be downloaded. If I click on this, it will take me into the find a view.
So, here we can see our library that we've been building and then also the library again, but with all of the third-party dependencies also packaged into it. This is a great result, it shows you really the capabilities of what you can do with GitHub Actions.
Okay, go ahead and close this lesson and I'll see you shortly in the next one, where I demonstrate refactoring the single workflow into a prod specific workflow in IDF specific workflow.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes.