image
Mockito Introduced to Mock Apache HttpClient HTTP Calls
Mockito Introduced to Mock Apache HttpClient HTTP Calls
Difficulty
Intermediate
Duration
1h 49m
Students
1019
Ratings
3.6/5
Description

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 support@cloudacademy.com.

Learning Objectives

  • 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

Intended Audience

  • Software developers interested in using TDD to build JDK11 based applications using Java

Prerequisites

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).

Resources

Transcript

Welcome back. In this lesson, I'm going to take you through the process of using mocking to mock out external dependencies. Now, if you recall, we left, our unit test in the following state from the previous lesson. That is, we were making live calls out to CoinDesk's, Bitcoin API.

Now what that means for our unit tests is that they've become integration tests and we don't want therefore unit testing. So how do we work around this? Well, we need a mocking framework. And in this particular demonstration, I'm going to introduce you to Mockito, which is a mocking framework for Java.

So what we'll need to do, is we'll need to install it, and download the dependencies for it. Now since we're using Maven, we can search with a Mockito library, in the Maven Central Repository. To do so, we'll navigate to search.maven.org. This website is the official Maven Central Repository search application.

So whenever you're working with Java and you're wanting to find a third party library then if you're using Maven, you can simply search for it within the Maven Central Repository application. So in our case, let's search for Mockito and down here, we've got the Mockito-core. So we'll click on that. We'll click on the latest version. And then over here, we simply copy this XML config and then jump back into our project and update our POM.

So under dependencies, I'll add in the new dependency. With the additional setting of updating the scope to be test only. The reason being is we only need it during the test phase. We'll save that. So now we jump into our unit test and this time we need to do some refactoring to introduce the concept of mocking into our unit test.

I'll now update our import statements. And here we can say that we need to import a lot of the same types, that we were already using in our implementation. The reason being is we want to mock a lot of the HTTP connection mechanics, such that we're actually simulating calls rather than making actual live calls within the class itself, only to set up a number of fields. Of they need to implement a setup method which has been tagged with the, before each annotation. And then here we make calls to mock and initialize each of the sub components that will make up our overall HTTP client. 

Importantly, within the setup method. we're also going to make a static payload of JSON. That is always returned. So this is going to contain the payload as if we'd made a real call to the CoinDesk's Bitcoin API. However, all the values are hard-coded and will always be static. Now, when it actually comes time to actually do the mocking, within the arrange section, I'm going to paste in the following for the first unit test.

Now, this portion of the code is our mocking setUp. Now I won't go through all of it, but the key point in here is that whenever there is a code to get the content then we're going to return in our mock, the stream which we previously set up and hard coded with a static payload, this payload here. So all of this together becomes our mock. And it all collapses into a mock client. So, therefore, we need to make sure our implementation actually uses our mock client. And the way we'll do that is to use dependency injection on the constructor of the Converter Service.

So on our implementation we'll provide a second constructor. And this one takes an input perimeter which is an HTTP client. And in our case, when we're running our unit test, we'll pass in the mock HTTP client, and then will simply set it on the HTTP client field. We'll head back to our test. And then the next thing well need to do is update the expected value.

For USD, we'll scan along and grab the USD value, which is this value here. Copy that, and we'll paste it here. Remembering that this is a double, so we need to get rid of the comma. We'll save it. And we'll clear the tests and we'll give it a go. I expect them to store file as they do, reviewing the results we can see that we've got a unreported exception.

So what I'll do is I'll, at the import, I'll scroll down and I'll just say that it throws for now IOException. Save that. We run the tests. Our tests have still failed. We'll scroll back to the results. And we can see that our first one has actually passed because we have run nine test and we failed eight times. So that's a good result because our first mock unit test has actually passed. So what we'll do is we'll go ahead and we'll update the remaining ones.

Okay, I'm going to navigate back to our GitHub repo and I'm going to swap over to step three, I'm going to navigate into source. I'm going to navigate into tests, and then all I'm going to do is I'm going to copy the remainder of our tests so that everything has been mocked out and you can do the same.

So in this case, I'm just going to overwrite all of our unit test with the same pattern. Save, and rerun the tests and excellent. Everything has returned back to green. Let's now summarize what we've actually just accomplished. So when we started off in this demonstration, our unit test had actually become integration test because they were making live calls to CoinDesk's, Bitcoin API. 

In this lesson I showed you how to use Mockito, which is a mocking framework for Java to mock out and simulate those calls to the CoinDesk's Bitcoin API and therefore making sure that our unit test were strictly unit test. Okay, go ahead and close this lesson and I'll see you in the next one where I'll do a final round of refactoring to introduce some additional unit tests that test error conditions.

About the Author
Students
143627
Labs
71
Courses
109
Learning Paths
209

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, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).