Category: Test Doubles And Mocks

  • What do others say about mocking?

    cAs I said, some developers favor mocking, and others do not. Software Engineering at Google, edited by Winters, Manshreck, and Wright (2020), has an entire dedicated to test doubles. Here’s what I understood from it, along with my own point of view:

  • Mocking types you do not own

    Mocking frameworks are powerful. They even allow you to mock classes you do not own. For example, we could stub the LocalDate class if we wanted to. We can mock any classes from any library our software system uses. The question is, do we want to? When mocking, it is a best practice to avoid mocking types…

  • Date and time wrappers

    Software systems often use date and time information. For example, you might need the current date to add a special discount to the customer’s shopping cart, or you might need the current time to start a batch processing job. To fully exercise some pieces of code, our tests need to provide different dates and times…

  • What to mock and what not to mock

    Mocks and stubs are useful tools for simplifying the process of writing unit tests. However, mocking too much might also be a problem. A test that uses the real dependencies is more real than a test that uses doubles and, consequently, is more prone to find real bugs. Therefore, we do not want to mock a dependency…

  • The disadvantages of mocking

    I have been talking a lot about the advantages of mocks. However, as I hinted before, a common (and heated) discussion among practitioners is whether to use mocks. Let’s look at possible disadvantages. Some developers strongly believe that using mocks may lead to test suites that test the mock, not the code. That can happen. When…

  • Mocks in the real world

    Now that you know how to write mocks and stubs and how you can write powerful tests with them, it is time to discuss best practices. As you can imagine, some developers are big fans of mocking. Others believe mocks should not be used. It is a fact that mocks make your tests less real.…

  • Simulating exceptions

    The developer realizes that SAP’s send method may throw a SapException if a problem occurs. This leads to a new requirement: The system should return the list of invoices that failed to be sent to SAP. A failure should not make the program stop. Instead, the program should try to send all the invoices, even though some of them…

  • Capturing arguments

    Imagine a tiny change in the requirements of sending the invoice to the SAP feature: Instead of receiving the Invoice entity directly, SAP now requires the data to be sent in a different format. SAP requires the customer’s name, the value of the invoice, and a generated ID. The ID should have the following format: <date><customer code>.…

  • Mocks and expectations

    Next, let’s discuss mocks. Suppose our current system has a new requirement: All low-valued invoices should be sent to our SAP system (a software that manages business operations). SAP offers a sendInvoice web service that receives invoices. You know you probably want to test the new class without depending on a real full-blown SAP web service. So,…

  • Stubbing dependencies

    Let’s learn how to use Mockito and set up stubs with a practical example. Suppose we have the following requirement: The program must return all the issued invoices with values smaller than 100. The collection of invoices can be found in our database. The class IssuedInvoices already contains a method that retrieves all the invoices. The code…