Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Mocking: it’s one of the most controversial topics in the testing world. Using mocks, we can more easily test parts of our applications that might otherwise go untested, but mocks can also be misused, resulting in tests that are brittle or downright self-referential. So… how do we know when to use mocks in our tests? In this talk, we’ll identify three important questions that can help us make that decision. By the end of the talk, you will have a framework in mind to help you answer the question: to mock, or not to mock?
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In her talk titled "To mock, or not to mock?" at RubyConf 2021, Emily Giurleo explores the intricacies of mocking in software testing. She begins by referencing Shakespeare's famous soliloquy to frame her discussion on the use of mocks in code tests, emphasizing the balance between their benefits and potential pitfalls. Emily aims to provide a framework to help developers determine when to use mocks effectively. The key points discussed throughout her presentation include: - **Understanding Mocks**: Emily explains two high-level approaches to testing: the classical approach, which focuses on creating real objects and checking their state, versus the mockist approach, which involves creating fake objects and verifying their behavior through expected interactions. - **Advantages and Disadvantages**: While traditional testing is simpler and more straightforward, over-reliance on mocking can lead to tests that are tightly coupled to code implementations, thereby making them fragile during code refactoring. Mocking can also result in self-referential tests that lack meaningful checks. - **Three Key Scenarios for Mocking**: Emily identifies three specific scenarios where using mocks can be particularly beneficial: - **Avoiding Expensive Resources**: Mocking can prevent costly operations such as network calls, which slow down tests or incur financial penalties due to API usage. She illustrates this through a mock of a network request client to test a quote-generating method without making actual API calls. - **Creating Deterministic Tests for Non-Deterministic Code**: Mocks help in testing aspects of code that exhibit unpredictable behavior, such as exceptions during network requests or random number generation that could lead to varying test outcomes. - **Testing Objects with Hidden States**: Certain objects, like caches, have states that should not be exposed or observed directly. Emily discusses a caching mechanism in her gem, Fake Sphere, and how mocking the cache methods allows for verifying interactions without exposing its internal state. - **Framework for Decision-Making**: Emily concludes with a framework comprising three critical questions when considering mocks: 1. Does the test use expensive resources (time, memory, or financial costs)? 2. Are we testing a non-deterministic code case? 3. Are we dealing with an object whose state cannot or should not be exposed? If any of these questions are answered affirmatively, it is a sign that using mocks would enhance the testing process. The session wraps up with a reminder to 'mock responsibly' and an invitation to engage with the community she co-founded, wnb.rb. Overall, Emily provides a well-rounded perspective on the nuanced use of mocks in software testing, emphasizing that while they can offer considerable advantages, they come with significant risks if misapplied.
Suggest modifications
Cancel
