--- title: "Capturing Mock Arguments" url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/capturing-mock-arguments.md" canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/capturing-mock-arguments/" tags: [] author: "Roy Osherove" description: "Lesson 13 of 21 in The Art of Unit Testing and TDD in Java (Day 2), 4:36. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Capturing Mock Arguments 1. [Courses](https://courses.osherove.com/#courses) 2. [The Art of Unit Testing and TDD in Java](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/) 3. Day 2 Lesson 13 of 21 Duration: 4:36 [Watch on YouTube](https://www.youtube.com/watch?v=gsuCaSHnKak) A short demo showing how you can capture the arguments sent to a [mock object](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_76 "Interaction testing, mocks, and stubs (The Art of Unit Testing, 3rd ed., ch. 4)") created with Mockito. ## In this lesson Roy Osherove shows Mockito's argument captor for checking that a trace message with specific attributes was sent to the logger, by capturing the argument in a verify call and asserting on its value. He calls this clumsy and compares it with a [handwritten fake](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec3 "A simple handwritten mock example (The Art of Unit Testing, 2nd ed., ch. 4)") class, which has to change whenever a method is added to the [logger interface](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_74 "Extracting a common interface (The Art of Unit Testing, 3rd ed., ch. 3)"). A participant suggests implementing equals on the trace message, which he says can be the most readable way when the object is simple. ## Transcript 665 words [\[00:03\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=3s) I want to show you quickly something. One of the exercises requires you to check that an a trace messages being sent to the logger with specific attributes. I want to show you how you can achieve that with Mockito. So Mockito has a special object called argument captor to capture arguments. And the way you use it is that you wait until the assert phase and then you create an argument captor of type trace message. [\[00:36\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=36s) So you declare it and you say give me an argument captor for class trace message.class and then you do a verify but instead of just saying write message with the with an object you say write message and you send in the the the argument captor.capture. capture and then once you have that you have you can get the value from the argument by saying get me the value put it in the object back you that and one now you'll have the object that was called with the values then you can assert on the severity or on the message of the object [\[01:15\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=75s) Now if that seems clumsy it's because it is it might be easier to write a [fake](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2 "The difference between mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)") class of your own to just capture the argument could be just as an idea. So it would be good to experiment both with this approach and by creating a class that inherits from the slow logger or implements the [logger interface](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_74 "Extracting a common interface (The Art of Unit Testing, 3rd ed., ch. 3)") whichever you want. Okay, just realize that the more [handwritten fake](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec7 "The problems with handwritten mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)") classes that you have, the more you will have to change them every time you add a method to the interface of the logger. [\[01:53\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=113s) That creates future [maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8 "Maintainability (The Art of Unit Testing, 3rd ed., ch. 8)"). But here it definitely costs us with some [readability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9 "Readability (The Art of Unit Testing, 3rd ed., ch. 9)"). Okay, so both of these methods are not great. One of them is not great in the future. The other is not great now. But it is a trade-off. There is no good way. There is only two bad ways to do it. Okay, if you want to verify an object on the [mock object](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4 "Interaction testing using mock objects (The Art of Unit Testing, 2nd ed., ch. 4)"), [\[02:23\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=143s) That's one of the only ways to do it. Now, it could be a design issue. Maybe we don't want to do that. Maybe we we could capture things and save them as public fields. But I would venture to say that if this if we're truly tr trying to send an object, we could try to beautify this code by doing maybe [helper methods](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec6 "Building a test API for your application (The Art of Unit Testing, 2nd ed., ch. 7)"), something like that. Extract all this into a method and say verify the call and get back the argument. [\[02:53\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=173s) We could try to refactor this to be a bit more readable. Okay. Questions, answers. What's your answer? >> The whole equals in the fake trace message, not fake trace message. >> Yeah. Oh, yeah. Of course, that's another way. Of course, I forgot about that. You could say that you might verify [\[03:28\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=208s) Mock log dot write message with a new trace message with severity and the message >> fails at first because the objects are not the same >> and first it fails because the objects are not the same instance. So you have to implement equals right. >> That's right source. >> Yeah. So this would actually yeah that would be a third way I completely forgot about I apologize because I am also stuck in my head about isolation frameworks. [\[04:03\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=243s) But this would be a good way to do things if you have an object pre-prepared with all the values that you want. But you have to remember that when you do this you're basically asserting on all the attributes of the object. If you have 20 of them, you have to set up 20 of these attributes. If you do this approach, you can pick and choose which attributes you care about. So it's always a trade-off. But here, yes, if you implement equals, that might be the most readable way if the object is quite clean and simple. [\[04:33\]](https://www.youtube.com/watch?v=gsuCaSHnKak&t=273s) >> Good. Good answer. ## Related - [Simulating fake values](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-5#ch05lev1sec3) · The Art of Unit Testing, 2nd ed., ch. 5 The 2nd edition's section on simulating fake values with a framework, including checking arguments passed to fakes. - [The problems with handwritten mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec7) · The Art of Unit Testing, 2nd ed., ch. 4 Section on problems with handwritten mocks and stubs, such as changing the fake whenever the interface grows. ### Also linked in this lesson #### The Art of Unit Testing, 3rd ed. - [Extracting a common interface](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-3#sigil_toc_id_74), ch. 3 - [Interaction testing, mocks, and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-4#sigil_toc_id_76), ch. 4 - [Maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8), ch. 8 - [Readability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9), ch. 9 #### The Art of Unit Testing, 2nd ed. - [A simple handwritten mock example](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec3), ch. 4 - [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4 - [Interaction testing using mock objects](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4), ch. 4 - [Building a test API for your application](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-7#ch07lev1sec6), ch. 7 [Previous lesson Isolation (Mocking) Frameworks](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/isolation-mocking-frameworks/) [Next lesson Extract And Override Refactoring](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/extract-and-override-refactoring/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/