[camera] Remove OCMock from CameraExposureTests and CameraFocusTests

[mchudy]

Extracted from #8342 to keep PRs smaller

• Introduces FLTDeviceOrientationProviding and FLTCaptureDeviceControlling protocols
• Removes OCMock.h reference from CameraExposureTests.h and CameraFocusTests.h

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[hellohuanlin]

Overall looks very good!

[hellohuanlin]

CC @LouiseHsu who recently did a pretty big swift migration for in-app purchase plugin.

[mchudy]

I'm not sure why the CI build fails. Locally it builds successfully. Do you have any tip maybe what can be the cause of this issue?

Failed to build iOS app
Lexical or Preprocessor Issue (Xcode): 'FLTCaptureDeviceControlling.h' file not found
/Volumes/Work/s/w/ir/x/w/packages/packages/camera/camera_avfoundation/ios/camera_avfoundation/Sources/camera_avfoundation/include/camera_avfoundation/FLTCamMediaSettingsAVWrapper.h:7:8

[hellohuanlin]

I'm not sure why the CI build fails. Locally it builds successfully. Do you have any tip maybe what can be the cause of this issue?

Failed to build iOS app
Lexical or Preprocessor Issue (Xcode): 'FLTCaptureDeviceControlling.h' file not found
/Volumes/Work/s/w/ir/x/w/packages/packages/camera/camera_avfoundation/ios/camera_avfoundation/Sources/camera_avfoundation/include/camera_avfoundation/FLTCamMediaSettingsAVWrapper.h:7:8

it's been a while since i touched this, but it sounds like either module map or umbrella header. I'd look into a similar header and see how it is setup.

[hellohuanlin]

I don't find a 2nd reviewer from the CODEOWNER for this plugin. Maybe @LouiseHsu who recently did a similar swift migration?

[mchudy]

I fixed the CI, kind of a workaround (for some reason I cannot get this to work with subfolders). I'm gonna try to fix that in further PRs, but I don't want to block this one.

[stuartmorgan]

It's not clear from the naming what all of the "Stub" methods are; they should be documented. And if I'm understand the purpose of these methods correctly, it seems like on* rather than *Stub would be a more idiomatic (and thus clearer to readers) name.

[mchudy]

I took it from this design doc where this kind of naming was used https://docs.google.com/document/d/1XsaulkJA6_ZSpM7chkQLhQY25sQqhEMiqHMYzw8H85o/edit?resourcekey=0-_cUjF1c0iBvRLKfV-3gK5A&tab=t.0
I'm completely fine with replacing it with on* prefix though, for sure sounds clearer.

[stuartmorgan]

Ah, I missed that in the doc. @hellohuanlin is there some source for that naming convention? The purpose of those methods does not at all match the use of "stub" I'm familiar with in tests.

[hellohuanlin]

No source - IIRC I wrote XXStub simply because it's to replace OCMStub(...).andDo(...). I am fine with any convention we discuss here.

[stuartmorgan]

Hm, looking at the doc again, and the methods here, maybe there's just a mismatch in usage in this PR. In the doc it looks more like what I expect something called stub to be, which is replacing what the method does. In the usage here, it's basically just a notifier:

- (void)setFocusMode:(AVCaptureFocusMode)mode {
  _focusMode = mode;
  if (self.setFocusModeStub) {
    self.setFocusModeStub(mode);
  }
}

It seems like this is trying to both be a simple stub object (which takes state to return) and sort of a dynamic stub (which would use stub methods) at the same time, and sometimes the latter is really a stub and other times (like the above) it's not.

We should decide what pattern we want to use for read/write properties. If it's that the getter and setter have real implementations in the stub object, then any supplemental callback shouldn't be called "stub" IMO, because it has nothing to do with what the object returns. If it's that we have stub methods, then those should be the whole implementation, and the object should be stateless other than the stub methods.

[mchudy]

Oh, you're right, that's a mistake on my part. I also pictured those stub methods as having no default implementation so _focusMode = mode assignment shouldn't be there. I corrected this.