Welcome back. Now that we've covered off the theory part of the course, we can begin the fun part, performing an actual test-driven development implementation. But before I do, I want to quickly review the design of what I'm about to build and the tools used to build it. In doing so, you'll have a clearer understanding of what is to be demonstrated. Therefore, let me first discuss the design basics regarding the Java library that we are going to build using test-driven development.

As seen here, the basic design of our test-driven development library involves the following. We're building a simple Java-based library that exposes a public interface for requesting and converting Bitcoins into foreign currency. The library will contain a single class named, converter SVC for service, which exposes two public methods.

GetExchangeRate takes a single input parameter representing the currency and then returns the current exchange rate for that currency. ConvertBitcoins on the other hand takes on two parameters. The first is the currency and the second is the number of Bitcoins to be converted. The library will be designed to integrate with CoinDesk's Bitcoin API using HTTP for communication. The library once compiled and built, will later be imported into a separate Java console-based project, which will allow us to leverage its capabilities by requesting console input from the user in the form of the currency and the number of Bitcoins they want to convert into.

Next, in terms of tooling, the following tools, frameworks, libraries and services have been used on Maco Wizz in the given demonstrations. This same set of tools, frameworks, libraries and services, together with the same code base, is completely cross-compatible and should be able to be performed on other operating systems, such as both Windows and or Linux.

Maven is used from the very start of the demonstrations to sit up and scaffold the initial Java 11-based library project structure, wiring it up with JUnit5 for testing as well. JUnit5 is a simple but powerful Java-focused unit testing framework. We use this to create and design our unit tests to test and validate our Java library code base.

Mockito provides a powerful but easy to use mocking framework, which enables us to mock out external dependencies. In the given coding demonstrations, we will use it to mock out CoinDesk's Bitcoin HTTP-based API, thereby removing the external dependency from the unit test.

GitHub Actions are a feature provided online within a GitHub repo and of which allow you to perform CICT-like build and or test jobs, et cetera. We will leverage a GitHub Action to automatically build and run our unit tests for us anytime we push code up into our repository. Additionally, we will configure our GitHub Action to automatically produce a visioned release earth at any time we push a tag up into the repository. 

Coveralls.io is a freely available online code coverage dashboard service that analyzes code coverage data and produces useful code coverage reports. In the given test-driven development coding demonstrations, we will automatically upload our unit is code coverage data into the service to allow us to quickly understand areas of code that aren't being tested.

In terms of our actual main coding, we'll use Visual Studio code, a freely available coding editor, which we'll use to create and edit the C-Sharp source code. Now again, our development will be undertaken using Java 11 and specifically with the OpenJDK version 11. Installing OpenJDK11 provides us with the Java and Javac command line tools, which Maven requires.

As a reminder and as previously mentioned in the course intro, all of the Java code base built and written using test-driven development practices as performed in the following demonstrations, can be found hosted publicly in Cloud Academy's GitHub account at this location. Note, the repository is structured using branches, a separate branch exists for each of the given demonstrations, therefore it should be easy for you to quickly jump to the areas of interest by simply swapping into the related Git branch.

Okay, that completes this lesson in which I reviewed both the design and tooling that will be used within the following test-driven development demonstrations. Go ahead now and close this lesson and I'll see you shortly in the first demonstration.