Flux - Learn to write JUNIT Tests
A free video tutorial from Pragmatic Code School
Technology Enthusiast, Online Instructor
4.5 instructor rating • 6 courses • 35,172 students
In this tutorial we will learn about how to write JUNITs for the Flux reactive type.
Learn more from the full courseBuild Reactive RESTFUL APIs using Spring Boot/WebFlux
Learn to write reactive programming in Spring using WebFlux/Reactor and build Reactive RESTFUL APIs.
09:38:13 of on-demand video • Updated February 2021
- What problems Reactive Programming is trying to solve ?
- What is Reactive Programming?
- Reactive Programming using Project Reactor
- Learn to Write Reactive programming code with DB
- Learn to Write Reactive Programming with Spring
- Build a Reactive API from Scratch
- Learn to build Non-Blocking clients using WebClient
- Write end to end Automated test cases using JUNIT for the Reactive API
English [Auto] Hi everyone. Welcome back to this tutorial. In this material learn about the techniques of writing the test cases that is going to assert on the elements that are part of the flux. I'm going to open the doors class flux on monitors when I zoom in a little bit and then let's go ahead and write the test case. I'm going to name this one as public. Wired Lux dust flux dust elements and then without error. So I'm not gonna have any error as part of the flux. So what I'm going to do I'm gonna just copy this first line and then put it here followed by that. I'm going to add the log so we have the flux right. The next thing is we are going to test the elements inside the flux which is Spring Spring springboard and react spring and then the order in which the elements are flowing to the subscriber. Right now in order to test the elements reactor test is a module that we are going to use. It has a class called Step purifiers. Let's create an instance of it. All right. I mean it's called the class and then it has a method called Create right for this method. We're going to pass the flux okay. That's good. And the next step is what is it we are expecting. Let's go and run this I'm on I want to hold onto those and then run this and then check what is that we are printing. So this is a test which we wrote in the previous video in here. If you take a look at the first value of spring the next value spring board and the next is a reactive spring. So that's what we have in our flux right. So the step very fair has handy methods like dot expect next. So in the expect next you can provide spring. That's a first value that we expect right. So that's a positive value. The flux is going to enter into the subscriber and then the next thing is what is the next value it's going to well minimize this or that the court will be clear like this. There you go. And then the next thing is it's going to be spring book. So I'm going to put the put the springboard here right. Let's put the double quotes and followed by that. What are the next value you expect next and the next value is a reactor spring. So I'm going to put that value to here. So let me farmer does three go. Now what we will do will try to run the Turkish and then what is the last want if we take a look at it since there is no error we are going to have the verify complete. Right. That's the last even we call the verify complete. That's when the actual data is going to flow okay. Now let's go out and run this particular grid that this case passed and then all the unions are flowing as expected just for the sake of making sure this works as expected. What I'm going to do I'm gonna change the order and then see what happens. So when we change the order the expectation is that we want to make sure this test fails. Let's go and run it. There you go that this case failed because we change the order the expectation as a springboard but it failed with the value spring. So this test case makes sure we are getting the elements from the flux in the order that we have it here. So the difference between these two is that here we call the subscript metal rate the subscript method is one which is going to complete which we just got to start the whole floor of the flux to pass the elements from the flux to the subscriber. But in here if we take a look at it the step very fair takes care of subscribing to the flux and then asserting the values on the flux. So does very fact complete if we do not call what happens what I'm going to do is I'm going to come on this and then show you what happens if we do not make a call to verify complete what happens let's go ahead and run this. You see here right. We did not have any events flowing from clocks. The reason being verified complete is a call which is actually equal and to subscribe. That's a one which is going to actually start the flow of elements from the fluxes so you have to make sure always you end up the test case with the verify call. Right now let's go and explore the next method which is flux test elements that error. So I'm gonna put with error and what I'm going to do is I'm gonna use the contact with which we have here. Let's copy this and then put it here. So the CONCATENATE is gonna add the exception. Right. And then here we are actually expecting the verified complete as a last event but that's not the case here because verify error is going to be the last word because we have the expected exception added to our flux. Let's go out and run this. Basically this test is gonna fail but still I want to show you what happens when you run it. So the expectation is expect complete. Let me zoom in a little bit. The expectation is expect complete but the actual is on error right. So how do we write test cases so that we can assert on the exception. So it is a handy method called expect. So put a dot expect error. So if you take a look at and expect error and then you can give runtime exception dark class. So here the exception type ers runtime exception that's the reason why I am putting the expected error under type of the exception as the argument toward the wafer complete won't work because what if a complete doesn't make sense here we are expecting the error rate. So in that case the methods that are available to us is just really fine. Let's go out and call this verify because verify is a one which is going to actually start the whole flow of flux from the a flux to the subscriber. So here are the step verified as a subscriber. Right. Let's go ahead and run this discuss if under the case. There we go. It gave you the green signal meaning that this case is working as expected. Let's say you want to just verify the message inside the exception. So in that case there is 100 method also available for that. So we're gonna do expect error message. There you go. Expect error message. And then we can pass the string as an input to that expected error message and then let's go out and run this. There you go and give it the green signal meaning that this case worked as expected. If you can we have both of these. The answer is No. You cannot have both. Together let's go out and run this one more time. There you go. So now let's say you do not want to validate all the values you just want to validate the number of elements that particular flux is going up so saying that is what we will do. So I'm gonna create another matter I'm going to copy this whole method and then put it here so I'm gonna name this one as let's minimize this flux elements flux elements count. So you just want to I saw it on the number of elements right. So this temporary Fair has a handy method for that called I expect next. So in the count you'll pass a value us three and then followed by that as per our use case we have an exception. That's the reason why I have the expected error message to be exceptional. Could you run this. It's gonna work as expected there we go. And I'm gonna show you one more variation here flux test with error only so flux tested with error. So here we have. I'm gonna name this one as a red one. Here we have expecting next as separate lines right. You don't hyper do what you can do this. You can just put everything in a single line to like this and followed by that you can do the reactive sipping what I'm going to do I'm going to remove these links and I'm one wonders where unders it's gonna give me the green signal. The reason being this is one of the other way of asserting on the elements in the flux. So these are the different approaches of testing the element and the flux. There are some odd ones to use cases which will be testing in the future tutorials but this we came to the end of this tutorial. Thank you for watching.