[MUSIC] Going to go out on a limb here and guest, if you're thinking of right in Java and kicks, and you probably have some experience of writing Java on another platform. May be, written in Java component for web application or even just a basic Java application to run on your laptop, if you have any, probably very few lines of code tested, it probably found a bug, because we aren't all perfect, fixed it, rinsed and repeat some familiar. She probably wants to do the same with the Java code about in the previous example, the first thing we want to do is to write some unit tests for Java code. If the concept of the intestine is Mewtwo you, then to quickly explain unit tests are automated test that stored alongside the programs that they're testing, and they test just a small unit of functionality. Now a good unit, I should only test the target program and not rely on any other programs or external services. Let's take a look at our server from a previous module as an example, we would want to write a unit test that called this module with the customer number as a string and returns an instance of the employee data object that contained the correct data. So let's have a look at that unit test, now, what happens when we run this test? Well, it's going to fail with the runtime exception when it tried to cool get employee, we shouldn't be surprised because as soon as our server attempts to use the kicks API, it fails as there isn't a kick system to run those API calls against. We can solve this by looking at 2 new technologies, mocking and remote, in which both key features of the new Jake access API, both of these technologies allow you to run and test your Java code locally on your work station. For our unit tests were just going to look at mocking for now, mocking, we can programmatically replace the objects in the kicks API with mock objects that return just the data that we have prepared, we can create these marks in the setup method of the test, annotated with that before, and this will get run before each test. Mockito is a well understood job based framework for creating mocks for use in J unit tests, although other mocking libraries but do exist, here, we can create mocks of all the kicks. API classes are payroll sadly uses and define the data that should be returned when those methods on those classes are called, this means that when are test runs, the mock objects will be used instead of the real objects in the Jake XX API. This in turn allows our unit test to only exercise the Java code that we have written and stop out the rest of the kids application. This means we can develop new methods within our Java class and get really false feedback from RJ unit test each time we build our project. In this example, we have just knocked out a simple Coulter kicks program with the channel and container interface for any class within the Jake execs API can be mocked. Buck in unit tests are a really good way of ensuring that the Java code that we've written works as we had planned, however, if you look at that setup method again, you will see that the data we've used for mocking the get method of the readable child container was hard coded into the test itself. But how would we get hold of that data in the 1st place so that we can use it within our test class? The answer lies in the Jake execs promoting capability, to describe this, let's revisit the server that we wrote in the last module, and I've just written the J unit tests for. As you can see, the server is running in a Liberty JVM server on my local laptop, it uses the Jake XX API to link to the program paper Swan with a channel we've shown how I can use mocking libraries to mock the calls from my servlet, not objects to stub out the communications with kicks. However, I can configure the application server in my local machine to use the Jake XX remoting capability instead, now, when my servlet accesses the Jake exacts API take Caroline visibly turn those causes HTTP coults which it sends to our real kick system. Within kicks are Jake exact server acts as an end point for the API and executes the kicks requests, this means that on your local machine, you can run and debug the application in your local server or getting real data back from kicks in. She could then, store for use in your unit tests, it must be noted that the remote incapabilities really only for test and development, and it isn't designed as a generic connector for Java applications to connect through to kicks. Now, what happens when we ready to run our application for rear wind sidekicks? Well, we just deploy the servlet from our local application server into kicks and this can be done as part of your maven or gradle build, when our server, it now runs, the Jake exacts APIs aware that we are now running inside of kicks and instead of using that remote connection. The API will use a standard across memory holds within kicks your code will behave exactly the same way and give you the same output whether you're running it locally on your machine or within Sidekicks. In this module, we've shown how writing a Java application for kicks is really just the same as writing a Java application anywhere else. You can build it locally, test it locally and then connect to kicks to test integration if your job and code can invest in kicks services. [MUSIC]
