Unit Testing in Spring Boot: Mocking, Mockito, and More — With a Side of Wit!

Introduction: "Wait, What? A Unit Test Course in 28 Minutes?"

Have you ever seen one of those "Unit Testing in 28 Minutes" courses and thought: "Wait, are you telling me that I'll learn all this stuff that has been scaring me for YEARS in 28 minutes? You must be joking."

I mean, you’ve spent countless hours trying to tame that wild beast called Mockito, and every time you think you’ve figured it out, it leaves you in the middle of a dark alley with its mocking behavior. And now you want me to learn it in 28 minutes? Are you calling me dumb? 😱

Well, today… let's give this a chance, shall we? Buckle up — we're diving into the wonderful world of Unit Tests in Spring Boot, and we’re going to make it fun. Yes, it’s possible!

What’s That Sound? Is It the Laughter of Mockito? Or the Horror?

1. Mocking with Mockito: The Silent Hero of Unit Testing

Let’s start with the basics. In the world of Unit Testing, the assertEquals(expectedResult, actualResult); statement is your best friend. It compares the two values — the expected and the actual — and if they match, the test passes. 🎉If they don’t, well… your test fails and your dreams are crushed. But hey, that’s testing for you!

Here’s the deal:

• Mockito is like your cool friend who helps you fake things to make your tests work. He’s not real, but he gets the job done.
• Mocking in testing means we are creating fake versions of dependencies, so we don’t have to talk to the actual database or service.

2. Stubbing: The Big Headache

Stubbing in tests is like trying to explain to your pet why they can’t eat your sandwich. It's hard to maintain, hard to keep organized, and if you're not careful, you’ll end up with hardcoded methods all over your code that make you want to scream.

Solution: Let Mockito handle it with mocking instead. You no longer need to give your objects a full backstory, just a little direction!

The Magical World of Mockito: Where Things Get REAL (Or Not)

3. Let’s Talk About Some Annotations in Mockito

Mockito has some cool features that will make you feel like a testing ninja:

• @Before vs @BeforeEach — No, this isn’t a debate about which is better for breakfast! @Before is the older annotation, and @BeforeEach is the new, more powerful version (Java 5 and beyond). Use it to set up common actions before each test.
• @InjectMocks — This is like asking Mockito to automatically inject the necessary mocks into the class you are testing.
• @Mock — This is where you specify the object you're going to pretend is real. You know, like that one friend who swears they can do 100 push-ups, but they’re secretly using a bunch of pillows to help.
• @RunWith(MockitoJUnitRunner.class) — Think of this as your personal butler. It’s the magic behind the scenes to make sure everything gets properly set up.

4. The Power of Argument Matchers:

Mockito has this amazing feature called Argument Matchers — it's like having a magic crystal ball that predicts what your arguments should be. 🧙♂️

For example, you can use anyInt() to match any integer argument, no matter what it is!

when(mock.get(anyInt())).thenReturn("Just exploring");
        

And then, no matter which integer you pass to mock.get(0) or mock.get(1), it will always return "Just exploring".

5. The Art of Verification: Like Catching Your Friends in the Act

Mockito also allows you to verify that things happened as expected. "Did you really call that method?" is a question that can now be answered like a pro.

For instance:

verify(mock).get(0); // Did you call get(0)?
verify(mock, times(1)).get(anyInt()); // Did you call get() exactly once?
        

It’s like you’re secretly watching your test to make sure it behaves.

6. Argument Capturing: "Aha! I Caught You!"

Sometimes, you’ll want to capture the arguments that were passed to your mock methods. That’s where ArgumentCaptor comes in. It’s like a ninja spy, silently observing what's happening in your tests.

ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
verify(mock).add(captor.capture());
assertEquals("Added String", captor.getValue());
        

It’s like saying, "I saw what you did there, and I’m capturing it!"

Spy vs Mock: The Ultimate Battle

Here’s a fun fact: Spying in Mockito is like peeking over your friend’s shoulder when they’re doing homework. You’re still testing the real object, but you’re watching it closely. On the other hand, mocking is more like building an entirely fake version of the object and telling it exactly how to behave.

When to Use spy() vs mock():

• Use spy() when you need to actually use some of the real functionality, but you want to control certain behaviors.
• Use mock() when you want a completely fake version of the object for the test.

Let’s Make It Fun with Code!

Here’s an example where Mockito does all the heavy lifting:

public class ListMockTest {
    List<String> mock = mock(List.class);

    @Test
    public void basicSize() {
        when(mock.size()).thenReturn(5);
        assertEquals(5, mock.size());
    }

    @Test
    public void returnDifferentValues() {
        when(mock.size()).thenReturn(5).thenReturn(10);
        assertEquals(5, mock.size());
        assertEquals(10, mock.size());
    }

    @Test
    public void argumentCapturing() {
        mock.add("Added String");

        ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
        verify(mock).add(captor.capture());

        assertEquals("Added String", captor.getValue());
    }

    @Test
    public void testSpy() {
        ArrayList<String> arrayListMock = spy(new ArrayList<>());
        arrayListMock.add("Test");
        assertEquals(1, arrayListMock.size());
    }
}
        

Conclusion: The End of the 28-Minute Learning Curse!

So, was this helpful? Are you now wondering how you managed to survive without Mockito in your life? 🙌

Unit testing doesn’t need to be a mystery. With Mockito and a little bit of wit, you’ll be mocking your way to cleaner code and better tests in no time. And just like that, in a mere 28 minutes, you’ve unlocked the power of unit testing!

Go ahead — test the world! Or at least test that one method that’s been giving you grief.

P.S. If you ever need more guidance, just remember: Mocking is fun. It’s not you, it’s the test.