Use real objects instead of mocks. #9523
Conversation
My motivation for making this change is that [`ByteBuffer` is becoming `sealed`](https://download.java.net/java/early_access/loom/docs/api/java.base/java/nio/ByteBuffer.html) in new versions of Java. This makes it impossible for Mockito's _current_ default mockmaker to mock it. That said, Mockito will likely [switch its default mockmaker](mockito/mockito#2589) to an alternative that _is_ able to mock `sealed` classes. However, there are downside to that, such as [slower performance](mockito/mockito#2589 (comment)), so it's probably better to leave our options open by avoiding mocking at all. And in this case, it's equally easy to use real objects. As a bonus, I think that real objects makes the code a little easier to follow: Before, we created mocks that the code under test never interacted with in any way. (The code just passed them through to a delegate.) When I first read the tests, I was confused, since I assumed that the mock we were creating was the same mock that we then passed to `verify` at the end of the method. That turned out not to be the case. Given that, I figured I'd switch not only to a real `ByteBuffer` but also to a real `OutputStream`.
|
The test failure looks unrelated to the change: |
|
Should we then replace all occurrences of ByteBuffer mocks with actual instances instead of this one test? Or is this the only one? Also you are right about the mock not being used in verify (or any other place). So one can very well use |
|
As far as I know, this is the only mock of |
|
OutputStream is strictly not necessary (other than it being confusing). Do you still want to keep it? |
|
I'm happy either way: Not only is the change not strictly necessary, it also doesn't address all mocking of |
|
I'll approve if you remove the OutputStream change. We still need another approver CC @ejona86 |
|
Removed, thanks. |
ejona86
added
the
kokoro:run
grpc-kokoro
removed
the
kokoro:run
|
I'm happy to see a mock die. |
My motivation for making this change is that [`ByteBuffer` is becoming `sealed`](https://download.java.net/java/early_access/loom/docs/api/java.base/java/nio/ByteBuffer.html) in new versions of Java. This makes it impossible for Mockito's _current_ default mockmaker to mock it. That said, Mockito will likely [switch its default mockmaker](mockito/mockito#2589) to an alternative that _is_ able to mock `sealed` classes. However, there are downside to that, such as [slower performance](mockito/mockito#2589 (comment)), so it's probably better to leave our options open by avoiding mocking at all. And in this case, it's equally easy to use real objects. As a bonus, I think that real objects makes the code a little easier to follow: Before, we created mocks that the code under test never interacted with in any way. (The code just passed them through to a delegate.) When I first read the tests, I was confused, since I assumed that the mock we were creating was the same mock that we then passed to `verify` at the end of the method. That turned out not to be the case.
My motivation for making this change is that
ByteBufferis becomingsealedin new versions of Java. This makes it impossible for Mockito's
current default mockmaker to mock it.
That said, Mockito will likely switch its default
mockmaker to an
alternative that is able to mock
sealedclasses. However, there aredownside to that, such as slower
performance,
so it's probably better to leave our options open by avoiding mocking at
all.
And in this case, it's equally easy to use real objects.
As a bonus, I think that real objects makes the code a little easier to
follow: Before, we created mocks that the code under test never
interacted with in any way. (The code just passed them through to a
delegate.) When I first read the tests, I was confused, since I assumed
that the mock we were creating was the same mock that we then passed to
verifyat the end of the method. That turned out not to be the case.Given that, I figured I'd switch not only to a real
ByteBufferbutalso to a real
OutputStream.