With 1.7.20-RC, I’ve noticed that mockito.argThat ...

# eap

[Zac Sweers]

With 1.7.20-RC, I’ve noticed that mockito.argThat no longer seems to work correctly. Trace in thread.

I personally don’t feel strongly about this (I don’t expect mockito to work well with Kotlin and don’t really want kotlin to cater to it 😅), just floating for awareness

[Zac Sweers]

value of              : getFileName()
expected to start with: WorkspaceUploadHelper.kt -> getTextUploadObservable
but was               : WorkspaceUploadHelper.kt -> invoke
value of              : getFileName()
expected to start with: WorkspaceUploadHelper.kt -> getTextUploadObservable
but was               : WorkspaceUploadHelper.kt -> invoke
	at slack.features.legacy.files.share.WorkspaceUploadHelperImplTest.startUpload___when_analytics_enabled_and_upload_text_fails___notifies_reports_error$lambda$49(WorkspaceUploadHelperImplTest.kt:1081)
	at org.mockito.internal.invocation.TypeSafeMatching.apply(TypeSafeMatching.java:35)
	at org.mockito.internal.invocation.MatcherApplicationStrategy.forEachMatcherAndArgument(MatcherApplicationStrategy.java:86)
	at org.mockito.internal.invocation.InvocationMatcher.argumentsMatch(InvocationMatcher.java:156)
	at org.mockito.internal.invocation.InvocationMatcher.matches(InvocationMatcher.java:82)
	at java.base@17.0.4.1/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
	at java.base@17.0.4.1/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
	at java.base@17.0.4.1/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base@17.0.4.1/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base@17.0.4.1/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
	at java.base@17.0.4.1/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base@17.0.4.1/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
	at org.mockito.internal.invocation.InvocationsFinder.findInvocations(InvocationsFinder.java:22)
	at org.mockito.internal.verification.checkers.MissingInvocationChecker.checkMissingInvocation(MissingInvocationChecker.java:33)
	at org.mockito.internal.verification.Times.verify(Times.java:37)
	at org.mockito.internal.verification.MockAwareVerificationMode.verify(MockAwareVerificationMode.java:30)
	at org.mockito.internal.handler.MockHandlerImpl.handle(MockHandlerImpl.java:75)
	at org.mockito.internal.handler.NullResultGuardian.handle(NullResultGuardian.java:29)
	at org.mockito.internal.handler.InvocationNotifierHandler.handle(InvocationNotifierHandler.java:34)
	at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:82)
	at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:56)
	at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor$DispatcherDefaultingToRealMethod.interceptAbstract(MockMethodInterceptor.java:161)
	at slack.telemetry.error.ErrorReporter$MockitoMock$vhsAmpYm.report(Unknown Source)
	at slack.features.legacy.files.share.WorkspaceUploadHelperImplTest.startUpload - when analytics enabled and upload text fails - notifies reports error(WorkspaceUploadHelperImplTest.kt:1078)

[Zac Sweers]

for a test like this

verify(mockErrorReporter)
  .report(
    argThat {
      assertThat(it.errorName).isEqualTo(MessageSendAttemptTrace.FAILED_ERROR_NAME)
      assertThat(it.fileName).startsWith("WorkspaceUploadHelper.kt -> getTextUploadObservable")
      true
    }
  )

[Zac Sweers]

hmmm actually digging in more, this might just be some weird thing in our test

[Zac Sweers]

basically it looks like stacktraces from lambdas are slightly different than before. Not sure it really matters. Will try to get an example of the diff for reference