Hi R.J. --> Thanks for reading the newsletter.
You're right, Mockito doesn't include anything specific for asynchronous coding, as you noted. I also use the StepVerifier when I'm using Project Reactor, almost always as part of a Spring app.
Still, Mockito can mock your dependencies, so if your reactive controller depends on a repository, for example, you can still mock that if you need to. For example, if you're testing a controller that returns a
returned by a reactive repository, you can still ask Mockito to return one of those using the
method to create one.
Hi Marco --> Mockito complements JUnit. Mockito tests are part of JUnit tests, though technically Mockito can work with other testing frameworks if you like. The vast majority are built on JUnit. The JUnit part sets up the class and methods you are testing and expresses the expected results as assertions. If the class you're testing has dependencies of its own, what Mockito can do is generate fake objects to represent those that return the desired values when called. You don't test the fakes. You test a class that depends on them.
If instead of using Mockito you use the real dependencies, that's fine. That's called an integration test (rather than a unit test), and it's a necessary part of making sure the system is working properly. I often think of it this way: if you drive a car to some destination, that's an integration test, or even a full end-to-end, or functional, test. If you get there and back, the test succeeded and you're good. But if something goes wrong, you take the car to a mechanic, and their job is to isolate the problem down to its source. Mockito helps you isolate one component from another, so you can diagnose where the real problems reside.
Hope that helps,
Ken