Mock Testing

Article Info

Contributed by
2 authors

Last updated on
2021-06-28 16:13:40

tools testing java

Mocking Framework
Test Doubles
Test-Driven Development
Unit Testing
Test Frameworks
Dependency Injection

Article Versions

14 2021-06-28 16:13:40
2601,1268 14,2601

By arvindpdmn

Spelling correction.
13 2019-03-20 16:13:47
1268,1237 13,1268

By arvindpdmn

Updates to all sections. Publishing.
12 2019-03-03 12:02:16
1237,1236 12,1237

By arvindpdmn

Spelling corrected. Formatting changes including refs/citations. Added See Also. Content review to follow.
11 2019-03-03 11:15:10
1236,1235 11,1236

By narendra

Update code source url
10 2019-03-03 08:18:24
1235,1234 10,1235

By narendra

Adding more discussions

Chat Room

Submitting ...

You are editing an existing chat message.
2021-06-28 16:14:10
-

By devbot5S

[URL Check] The following URLs in this article are outdated. Please update.

Redirected URLs:
References: https://www.soapui.org/learn/mocking/what-is-api-mocking.html → https://www.soapui.org/learn/mocking/what-is-api-mocking/
References: https://zeroturnaround.com/rebellabs/how-to-mock-up-your-unit-test-environment-to-create-alternate-realities/ → https://www.jrebel.com/blog/mock-unit-testing-with-mockito
2019-03-24 09:32:31
-

By arvindpdmn

Already reviewed last week on call. Recording it here for reference.

1. Summary: most important section. If readers find this difficult, they will not read the rest of the article. Our aim is to provide simple explanation. The first para is okay but should be immediately followed by an example. Second para can then follow the example. An example comes in the last para. This can be moved up. The final text is mostly a rewrite based on this formula: context, problem, solution, example.
2. Very important to avoid plagiarism: "We don’t want to send e-mails each time we run a test. Moreover, it is not easy to verify in tests that a right email was send." This is an exact copy from the source. We use exact copy only for quotes.
3. Summary: "Mocking is creating objects that mimic or simulate the behaviour of real objects." Not sure. I thought mocking is more about the interface calls rather than behaviour of dependencies.
4. Add single space after punctuations: . , ; , ? etc. However, there should be no space when punctuation is followed by citation: eg. This is fine.
5. "What are fakes, stubs and Mocks?": moved to Test Doubles article.
6. Research: one of the references leads to a useful paper: http://www.mockobjects.com/files/mockrolesnotobjects.pdf This is an excellent reference to improve the article.
7. Wisdomjobs.com is probably not a good reference. The article is too short. No comments section or voting from readers.
7. Question on framework: okay. A more detailed article on the topic can be created later. Hence keep information about frameworks minimal.
8. Test Doubles: image is not of good resolution. Text is too small and not readable. In fact, Test Doubles is now a separate article. Hence, select instead an image that shows only the Mock part.
9. Lack of citations for some milestones.
10. Milestones must be written in first tense. Eg. "EasyMock was the first mock object library that provided dynamic mock objects, have been created by Tammo Freese at OFFIS, preceding both Ruby/Mock and DynaMock" --> "Tammo Freese at OFFIS creates EasyMock. It's probably the first mock object library to provide dynamic mock objects, predating both Ruby/Mock and DynaMock"
11. Good job with citation for images.
2019-03-03 08:21:34
-

By narendra

Updated as per suggestions.

1. Updated Summary with example and diagrams.
2. Formatted References.
3. Added more discussions for Mock Object, Mocking types and removed Mocking Framework.
Please review
2019-02-27 04:19:53
-

By arvindpdmn

1. Mocking framework can be separate article. Move related content to a separate article.
2. From my earlier comment, does it make sense to talk about types of mock testing and best practices?
3. Don't rely too much on Wikipedia references. Not the best source. A single wiki page is really only one reference.
4. There's no clear example to convey what is mock testing. This should be in Summary. Current summary will be hard to understand for someone not from testing background. A picture also would help.
2019-02-27 04:09:57
-

By arvindpdmn

Please follow correct format for references. For example, you have written:
Michal, Lipski. 2017. "Test Doubles", Last modified Mar 2017.

It should be:
Michal, Lipski. 2017. "Test Doubles — Fakes, Mocks and Stubs." Pragmatists, on Medium, March 30. Accessed 2019-02-27.

Format is:
Lastname, Firstname. Year. "Title." Website name, Month Date. Accessed YYYY-MM-DD.

Mocking external components. Source: SoapUI 2019.

Mock testing is an approach to unit testing that lets you make assertions about how the code under test is interacting with other system modules. In mock testing, the dependencies are replaced with objects that simulate the behaviour of the real ones. The purpose of mocking is to isolate and focus on the code being tested and not on the behaviour or state of external dependencies.

Let's say, a notification service triggers an email service. We don't want to send emails each time we run a notification test. However, we want to verify that the email-sending service is called. Such a service can be replaced with a mock object.

Discussion

Where is mock testing useful?
Common uses of mocking. Source: SoapUI 2019.
Mocking is generally useful during unit testing so that external dependencies are no longer a constraint to the unit under test. Often those dependencies may themselves be under development. Without mocking, if a test case fails, it will be hard to know if the failure is due to our code unit or due to dependencies. Mocking therefore speeds up development and testing by isolating failures.
Other reasons to mock dependencies is to avoid slow network calls or call third-party APIs. Mocking also enables product demos and evaluations. All units of a project can progress in parallel without waiting for everyone to be ready. Thus, testing can start early.
Code that have side effects should be called only in production. Examples include charging a credit card or sending a notification. Mocking is useful to validate such calls without the side effects.
Mocking avoids duplicating test code across similar tests. The task of verifying method or API calls from our module can be delegated to the mock.
Could you give some examples of mock testing?
Use of the Mock Network Provider avoids external API calls. Source: Agostini 2017.
Let's say, an Order class fulfils orders by calling a Warehouse class. The latter knows the current inventory. If we are unit testing Order class, we mock the Warehouse. We don't care about testing Warehouse right now. But since it's a dependency for Order, we mock it. Our mock object can be called WarehouseMock.
A mock object provides a pseudo implementation of the same interface as the real object. Those calling it are unaware that it's a mock. Thus, to the Order class, WarehouseMock looks the same as Warehouse. This is just what we need to unit test Order class.
Another example is about an application calling an external API to get information about movies. Instead of making real calls, this can be mocked so that when API calls are made, the mock object will simply read and respond with test data from a local file system.
Does mocking require developers to modify their codebase?
If your code uses static objects or singletons, then it's difficult to do mocking. In such cases, it's better to refactor code. Otherwise, in general, mocking doesn't require you to modify the codebase. In fact, dependency injection is the usual way in which objects should be created. Dependencies become visible in the constructors and other methods. These dependencies can therefore be easily replaced during testing with mock objects. This can be configured either in code or via a configuration file.
How is mock testing different from traditional unit testing?
Mocks replace actual Door and Window objects. Source: Lipski 2017.
In traditional unit testing, unit tests do assertions about states expected of either the system under test or its dependencies. With mock testing, no assertions are required from the unit tests themselves. Assertions are done by the mock objects. These objects are initialized in advance about what method calls are expected and how they should respond.
While unit tests are more about state-based verification, mock testing is more about behaviour-based verification. For example, let's assume that SecurityCentral is being tested. It depends on Door. When SecurityCentral activates full security, unit testing will verify the final state of Door, that it's closed. Mocking would instead verify that the correct method was invoked with expected arguments, such as Door.close(). Mocks register the calls they receive so these can be asserted.
What are the common types of mock testing?
In proxy-based mocking, a proxy object is used instead of the original object. The proxy may handle all calls to the original object or selectively forward some calls. Mock frameworks such as EasyMock, JMock, Mockito offer this type of mocking. However, there may be limitations in terms of proxying static/private/final methods or a final class.
In classloader-remapping-based mocking, a class loader remaps the reference. Thus, it loads the mock object rather than the original one. Mock frameworks such as JMockit and PowerMock support this. This overcomes the limits of proxy-based mocking.
In Swift language, one developers blogged that he uses two ways to do mocking: instance injection and configuration injection. The former is simpler but it can't handle static objects.
What are some best practices for mock testing?
Here are some best practices for mocking:
- Only mock types that you own: External types have dependencies on their own. They might even change their behaviour in a future version. Instead, create an adapter and mock that adapter.
- Don't mock values: Values should not be mocked. Mocking aims to make the relationships and interactions between objects visible. Getting a value is not an interaction.
- Avoid mocking concrete classes: Relationships are easier to see via interfaces rather than concrete classes. We might end up mocking some methods but forget others. Mock roles, not objects.
- Don't mock everything: This is an anti-pattern. If everything is mocked, we may end up testing something quite different from production system.
- Use integration tests: When testing multiple modules or if you're interested in data coming from an external database, you should do integration testing rather than mocking.
- Negative tests: Use mocks to simulate errors and test error handling. Use mocks to verify that some methods/APIs are not called.
What are some mocking frameworks?
While it's possible to manually write mock objects, mocking frameworks simplify the task. Mockito is an open source testing framework for Java. Mockito is claimed to be the one of the popular ones.
JustMock and MOQ package are useful for .NET developers. . There's also JustMock Lite when dealing with loosely coupled code. Wiremock is suitable for mocking HTTP-based APIs.
For C++ developers, there's TypeMock and Google Mock. The latter is part of GoogleTest. TypeMock uses a templating approach to create mocks whereas Google Mock uses inheritance.
Other frameworks include EasyMock, JMock, JMockit, and PowerMock. Ease of use, maintainability and learning curve are some things to consider when choosing a framework.
What are some limitations of mock testing?
Writing good mocks requires good understanding of dependencies. Otherwise, mocks may not accurately represent real-world behaviour. Mocking can lead to tight coupling between mocks and code under test.
Overuse of mock objects as part of a suite of unit tests can result in a dramatic increase in the amount of maintenance that needs to be performed on the tests themselves.

Milestones

1999

Extreme Programming emphasizes unit testing and Test-Driven Development (TDD). Some adopters of Extreme Programming, based out of London, begin to think about how testing influences coding. They have been using "getters" to facilitate testing but they explore new ideas. They start avoiding "getters" and adopt composition, where test objects are passed via constructors. This is years before the term Dependency Injection is used for this design approach.

2000

Initial ideas of mock testing are presented at the XP2000 conference. At this time, the approach is called Endo-Testing. This name comes from the fact that mock objects are passed into domain code and tested from within. They claim that this simplifies testing architecture. It avoids polluting domain code since assertions are not in production code but in unit tests.

2001

EasyMock is released. It's the first library to provide dynamic mock objects.

Jun
2004

Version 1.0.0 of jMock is released. This provides an expressive API over DynaMock Java library. DynaMock itself comes from an earlier work by Nat Pryce who introduced mocking to Ruby. He emphasized assertions on messages passed between objects rather than just parameter values.

Jul
2008

Framework Mockito v1.5 for Java is released. By now, mock testing is more than just identifying where a test has failed. It's more about interactions among objects. Mockito simplifies mocking by taking a different approach compared to jMock or EasyMock. We don't have to set up expectations in mock objects in advance. We can simply create them and query them later after execution.

Apr
2007

Nat Pryce and Steve Freeman rework jMock to produce jMock2.

Dec
2008

Google releases Google Mock, a mocking framework for C++. Version 1.7.0 is released in 2013. In 2015, this is absorbed into the GoogleTest project.

Sample Code

java
Mockito

// Source: http://www.softwaretestingmagazine.com/knowledge/unit-testing-fakes-mocks-and-stubs/
// Accessed: 2019-03-03
 
// When testing SecurityCentral, we use mocks to verify
// that doors and windows are correctly instructed to close.
public class SecurityCentralTest {
    Window windowMock = mock(Window.class);
    Door doorMock = mock(Door.class);
 
    @Test
    public void enabling_security_locks_windows_and_doors() {
        SecurityCentral securityCentral = new SecurityCentral(windowMock, doorMock);
        securityCentral.securityOn();
        verify(doorMock).close();
        verify(windowMock).close();
    }
}

// Source: Kapelonis 2016
// Accessed: 2019-03-20
 
// Example showing the use of Mockito framework.
// FinalInvoiceStep calls PrinterService and EmailService, which are mocked.
 
public class FinalInvoiceStepTestMocked {
    private FinalInvoiceStep finalInvoiceStep = null;
    private Customer customer = null;
    private Invoice invoice = null;
    private PrinterService printerService = null;
    private EmailService emailService =null;
 
    @Before
    public void beforeEachTest() {
        printerService = Mockito.mock(PrinterService.class);
        emailService = Mockito.mock(EmailService.class);
        customer = new Customer();
        // Notice how we use Dependency Injection here
        finalInvoiceStep = new FinalInvoiceStep(printerService, emailService);
        invoice = new Invoice();
    }
 
    @Test
    public void normalCustomer() {
        customer.wantsEmail(true);
        finalInvoiceStep.handleInvoice(invoice, customer);
        //Nothing should be printed
        Mockito.verifyZeroInteractions(printerService); 
        //Something must be emailed 
        Mockito.verify(emailService).sendInvoice(invoice, customer.getEmail());
    }
 
    @Test
    public void customerWithPrintedInvoice() {
        customer.wantsEmail(false);
        finalInvoiceStep.handleInvoice(invoice, customer);
        //Nothing should be  emailed
        Mockito.verifyZeroInteractions(emailService); 
        //The invoice must be printed
        Mockito.verify(printerService).printInvoice(invoice); 
    }
}

References

Article Stats

1465

Words

Authors

Edits

Chats

Likes

57K

Hits

Cite As

Devopedia. 2021. "Mock Testing." Version 14, June 28. Accessed 2023-11-12. https://devopedia.org/mock-testing

Contributed by
2 authors

Last updated on
2021-06-28 16:13:40

tools testing java

Mocking Framework
Test Doubles
Test-Driven Development
Unit Testing
Test Frameworks
Dependency Injection

Mock Testing

Discussion

Milestones

Sample Code

References

Further Reading

Article Stats

Author-wise Stats for Article Edits

Cite As

See Also

Login