Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2815823002:
Add unit test class for RTCCameraVideoCapturer. (Closed)
|
Created:
3 years, 8 months ago by daniela-webrtc Modified:
3 years, 7 months ago CC:
webrtc-reviews_webrtc.org, tterriberry_mozilla.com Target Ref:
refs/heads/master Project:
webrtc Visibility:
Public. |
DescriptionAdd unit test class for RTCCameraVideoCapturer.
To achieve higher testability, some internally used ivars needed to be syntesized as properties
and some methods needed to be refactored.
BUG=webrtc:7177
Review-Url: https://codereview.webrtc.org/2815823002
Cr-Commit-Position: refs/heads/master@{#17971}
Committed: https://chromium.googlesource.com/external/webrtc/+/c1524301f72f1764bfe8b86134170e12dad68761
Patch Set 1 #
Total comments: 12
Patch Set 2 : Add tests that test only the public interface #Patch Set 3 : Add tests that test only the public interface #
Total comments: 14
Patch Set 4 : Revert declaring ivars as properties #
Total comments: 6
Patch Set 5 : Add comments #Patch Set 6 : Fix compilation for mac #Patch Set 7 : Fix compilation for mac #Patch Set 8 : Fix compilation for mac #Messages
Total messages: 31 (16 generated)
denicija@webrtc.org changed reviewers: + magjed@webrtc.org, sakal@webrtc.org
Thanks for adding tests. However, we need to discuss how we should do these unit tests. Right now, a lot of internal member variables and functions have been exposed to the tests. I don't want to directly test an objects internals. For example, we don't even know if we will have an internal member variable called |willBeRunning| in the future, so directly accessing it in the test just cements that implementation detail and will be an annoyance in future refactorings. We should focus on testing the public interface of the class instead, and only mock external dependencies (AVFoundation and the orientation notifications in this case). https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:84: - (void)testSetupSession { This test is good https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:91: EXPECT_EQ(sessionOutput, self.capturer.videoDataOutput); except that we can't make this check since it's an internal object. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:100: [self.capturer setupCaptureSession]; You can't test this directly since it's an internal function. You'll have to work with the public interface, e.g. test what happens when you call startCaptureWithDevice twice in a row. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:110: AVCaptureVideoDataOutput *videoOutput = self.capturer.videoDataOutput; Is it possible to extract this object through the public interface? Otherwise we have to drop this test. Or we make setupVideoDataOutput a static function that returns an AVCaptureVideoDataOutput and test that static function instead. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:118: - (void)testSetupSessionOutputSecondCall { Same here, we can't test this directly. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:132: - (void)testWillBeRunningFlagIsFalse { We have to change this test to check e.g. that we don't receive frames after starting and stopping immediately instead of testing the internal |willBeRunning| variable. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:153: - (void)testSupportedFormatsForDevice { This test is good. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:189: - (void)testStartCapture { This test is interesting, but if we want to properly support startCaptureWithDevice failing (because e.g. the passed in AVCaptureDevice is locked), we need to add a onSuccess/onError callback for startCaptureWithDevice so consumers without internal access have a way of getting notified about the result.
On 2017/04/13 11:13:06, magjed_webrtc wrote: > Thanks for adding tests. However, we need to discuss how we should do these unit > tests. Right now, a lot of internal member variables and functions have been > exposed to the tests. I don't want to directly test an objects internals. For > example, we don't even know if we will have an internal member variable called > |willBeRunning| in the future, so directly accessing it in the test just cements > that implementation detail and will be an annoyance in future refactorings. We > should focus on testing the public interface of the class instead, and only mock > external dependencies (AVFoundation and the orientation notifications in this > case). I don't think testing the public interface is gonna fully cover all the test cases for this class. Let's discuss IRL when I'm back and weigh the pro's and con's of both approaches. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:84: - > (void)testSetupSession { > This test is good > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:91: > EXPECT_EQ(sessionOutput, self.capturer.videoDataOutput); > except that we can't make this check since it's an internal object. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:100: > [self.capturer setupCaptureSession]; > You can't test this directly since it's an internal function. You'll have to > work with the public interface, e.g. test what happens when you call > startCaptureWithDevice twice in a row. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:110: > AVCaptureVideoDataOutput *videoOutput = self.capturer.videoDataOutput; > Is it possible to extract this object through the public interface? Otherwise we > have to drop this test. Or we make setupVideoDataOutput a static function that > returns an AVCaptureVideoDataOutput and test that static function instead. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:118: - > (void)testSetupSessionOutputSecondCall { > Same here, we can't test this directly. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:132: - > (void)testWillBeRunningFlagIsFalse { > We have to change this test to check e.g. that we don't receive frames after > starting and stopping immediately instead of testing the internal > |willBeRunning| variable. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:153: - > (void)testSupportedFormatsForDevice { > This test is good. > > https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:189: - > (void)testStartCapture { > This test is interesting, but if we want to properly support > startCaptureWithDevice failing (because e.g. the passed in AVCaptureDevice is > locked), we need to add a onSuccess/onError callback for startCaptureWithDevice > so consumers without internal access have a way of getting notified about the > result.
Changed the tests to test only publicly exposed methods and properties. Can you take a look? And see if there is some test case that I've missed that could be added. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:110: AVCaptureVideoDataOutput *videoOutput = self.capturer.videoDataOutput; On 2017/04/13 11:13:06, magjed_webrtc wrote: > Is it possible to extract this object through the public interface? Otherwise we > have to drop this test. Or we make setupVideoDataOutput a static function that > returns an AVCaptureVideoDataOutput and test that static function instead. Done. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:132: - (void)testWillBeRunningFlagIsFalse { On 2017/04/13 11:13:06, magjed_webrtc wrote: > We have to change this test to check e.g. that we don't receive frames after > starting and stopping immediately instead of testing the internal > |willBeRunning| variable. This test case intends to test that dealloc doesn't assert when stopCapture has not been performed. But dealloc is difficult to test reliably and accurately. So it's better to drop this test case. https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:189: - (void)testStartCapture { On 2017/04/13 11:13:06, magjed_webrtc wrote: > This test is interesting, but if we want to properly support > startCaptureWithDevice failing (because e.g. the passed in AVCaptureDevice is > locked), we need to add a onSuccess/onError callback for startCaptureWithDevice > so consumers without internal access have a way of getting notified about the > result. If we want to change the API we should do that as soon as possible.
https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/1/webrtc/sdk/objc/Framework/Uni... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:189: - (void)testStartCapture { On 2017/04/26 11:43:38, daniela-webrtc wrote: > On 2017/04/13 11:13:06, magjed_webrtc wrote: > > This test is interesting, but if we want to properly support > > startCaptureWithDevice failing (because e.g. the passed in AVCaptureDevice is > > locked), we need to add a onSuccess/onError callback for > startCaptureWithDevice > > so consumers without internal access have a way of getting notified about the > > result. > > If we want to change the API we should do that as soon as possible. Ok, let's keep the API intact and not support passing in locked AVCaptureDevice. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/Classes/RTCCameraVideoCapturer.m (right): https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/Classes/RTCCameraVideoCapturer.m:30: @property(nonatomic, strong) AVCaptureVideoDataOutput *videoDataOutput; Should we revert these changes and only have them as ivars again? https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/Classes/RTCCameraVideoCapturer.m:32: @property(nonatomic, strong) dispatch_queue_t frameQueue; I would like to make frameQueue readonly again. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:21: CMSampleBufferRef createMockSampleBufferRef() { This is nice! We will probably need something similar for a fake capture. Is the name 'createMock' here appropriate? It's a real CMSampleBufferRef. Maybe the name createTestSampleBufferRef is better? https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:142: OCMStub([self.deviceMock devicesWithMediaType:AVMediaTypeVideo]).andReturn(@[ [NSObject new] ]); Remove duplicate line https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:165: - (void)testDelegateCallbackWithValideBufferAndOrientationUpdate { spelling nit: Valide https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:187: WAIT(0, 1000); I think it's preferable in this case to expose '(void)updateOrientation:(UIDeviceOrientation)orientation;' and call that directly instead like you used to do.
https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/Classes/RTCCameraVideoCapturer.m (right): https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/Classes/RTCCameraVideoCapturer.m:30: @property(nonatomic, strong) AVCaptureVideoDataOutput *videoDataOutput; On 2017/04/26 14:12:08, magjed_webrtc wrote: > Should we revert these changes and only have them as ivars again? Done. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/Classes/RTCCameraVideoCapturer.m:32: @property(nonatomic, strong) dispatch_queue_t frameQueue; On 2017/04/26 14:12:08, magjed_webrtc wrote: > I would like to make frameQueue readonly again. Done. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:21: CMSampleBufferRef createMockSampleBufferRef() { On 2017/04/26 14:12:09, magjed_webrtc wrote: > This is nice! We will probably need something similar for a fake capture. Is the > name 'createMock' here appropriate? It's a real CMSampleBufferRef. Maybe the > name createTestSampleBufferRef is better? Done. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:142: OCMStub([self.deviceMock devicesWithMediaType:AVMediaTypeVideo]).andReturn(@[ [NSObject new] ]); On 2017/04/26 14:12:08, magjed_webrtc wrote: > Remove duplicate line This line is not duplicate. The first one mocks AVMediaTypeVideo the second AVMediaTypeAudio devices. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:165: - (void)testDelegateCallbackWithValideBufferAndOrientationUpdate { On 2017/04/26 14:12:08, magjed_webrtc wrote: > spelling nit: Valide Done. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:187: WAIT(0, 1000); On 2017/04/26 14:12:09, magjed_webrtc wrote: > I think it's preferable in this case to expose > '(void)updateOrientation:(UIDeviceOrientation)orientation;' and call that > directly instead like you used to do. I'd prefer to keep this test as is because it tests the notification observing and the orientation change. It's slightly more complicated but it provides better coverage.
https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:142: OCMStub([self.deviceMock devicesWithMediaType:AVMediaTypeVideo]).andReturn(@[ [NSObject new] ]); On 2017/04/27 09:40:20, daniela-webrtc wrote: > On 2017/04/26 14:12:08, magjed_webrtc wrote: > > Remove duplicate line > > This line is not duplicate. The first one mocks AVMediaTypeVideo the second > AVMediaTypeAudio devices. Acknowledged. https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:187: WAIT(0, 1000); On 2017/04/27 09:40:20, daniela-webrtc wrote: > On 2017/04/26 14:12:09, magjed_webrtc wrote: > > I think it's preferable in this case to expose > > '(void)updateOrientation:(UIDeviceOrientation)orientation;' and call that > > directly instead like you used to do. > > I'd prefer to keep this test as is because it tests the notification observing > and the orientation change. It's slightly more complicated but it provides > better coverage. Ok, it's the WAIT in particular I don't like. Is it possible to wait only until the dispatch has finished instead?
On 2017/04/27 14:48:12, magjed_webrtc wrote: > https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... > File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): > > https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:142: > OCMStub([self.deviceMock devicesWithMediaType:AVMediaTypeVideo]).andReturn(@[ > [NSObject new] ]); > On 2017/04/27 09:40:20, daniela-webrtc wrote: > > On 2017/04/26 14:12:08, magjed_webrtc wrote: > > > Remove duplicate line > > > > This line is not duplicate. The first one mocks AVMediaTypeVideo the second > > AVMediaTypeAudio devices. > > Acknowledged. > > https://codereview.webrtc.org/2815823002/diff/40001/webrtc/sdk/objc/Framework... > webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:187: WAIT(0, > 1000); > On 2017/04/27 09:40:20, daniela-webrtc wrote: > > On 2017/04/26 14:12:09, magjed_webrtc wrote: > > > I think it's preferable in this case to expose > > > '(void)updateOrientation:(UIDeviceOrientation)orientation;' and call that > > > directly instead like you used to do. > > > > I'd prefer to keep this test as is because it tests the notification observing > > and the orientation change. It's slightly more complicated but it provides > > better coverage. > > Ok, it's the WAIT in particular I don't like. Is it possible to wait only until > the dispatch has finished instead? Not sure it's possible to reliably know when the dispatching has finished. I don't like the wait either but cannot think of better way
lgtm
lgtm https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:32: CGContextRef context = CGBitmapContextCreate(nil, size.width, size.height, 8, 8 * size.width, nit: can you add comment on these magic numbers https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:109: CMVideoFormatDescriptionCreate(nil, kCVPixelFormatType_420YpCbCr8PlanarFullRange, 123, 456, nil, nit: can you add comment on these magic numbers + nils https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:156: nit: remove empty line
https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... File webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm (right): https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:32: CGContextRef context = CGBitmapContextCreate(nil, size.width, size.height, 8, 8 * size.width, On 2017/04/28 11:20:32, sakal wrote: > nit: can you add comment on these magic numbers Done. https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:109: CMVideoFormatDescriptionCreate(nil, kCVPixelFormatType_420YpCbCr8PlanarFullRange, 123, 456, nil, On 2017/04/28 11:20:32, sakal wrote: > nit: can you add comment on these magic numbers + nils Done. https://codereview.webrtc.org/2815823002/diff/60001/webrtc/sdk/objc/Framework... webrtc/sdk/objc/Framework/UnitTests/RTCCameraVideoCapturerTests.mm:156: On 2017/04/28 11:20:32, sakal wrote: > nit: remove empty line Done.
The CQ bit was checked by denicija@webrtc.org
The patchset sent to the CQ was uploaded after l-g-t-m from magjed@webrtc.org, sakal@webrtc.org Link to the patchset: https://codereview.webrtc.org/2815823002/#ps80001 (title: "Add comments")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_baremetal on master.tryserver.webrtc (JOB_FAILED, http://build.chromium.org/p/tryserver.webrtc/builders/mac_baremetal/builds/21150)
The CQ bit was checked by denicija@webrtc.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_rel on master.tryserver.webrtc (JOB_FAILED, http://build.chromium.org/p/tryserver.webrtc/builders/mac_rel/builds/25285)
The CQ bit was checked by denicija@webrtc.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by denicija@webrtc.org
The patchset sent to the CQ was uploaded after l-g-t-m from magjed@webrtc.org, sakal@webrtc.org Link to the patchset: https://codereview.webrtc.org/2815823002/#ps140001 (title: "Fix compilation for mac")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
CQ is committing da patch.
Bot data: {"patchset_id": 140001, "attempt_start_ts": 1493720297381810,
"parent_rev": "fa18e25461c258dca30bd3c382863411f8c3b77b", "commit_rev":
"c1524301f72f1764bfe8b86134170e12dad68761"}
Message was sent while issue was closed.
Description was changed from ========== Add unit test class for RTCCameraVideoCapturer. To achieve higher testability, some internally used ivars needed to be syntesized as properties and some methods needed to be refactored. BUG=webrtc:7177 ========== to ========== Add unit test class for RTCCameraVideoCapturer. To achieve higher testability, some internally used ivars needed to be syntesized as properties and some methods needed to be refactored. BUG=webrtc:7177 Review-Url: https://codereview.webrtc.org/2815823002 Cr-Commit-Position: refs/heads/master@{#17971} Committed: https://chromium.googlesource.com/external/webrtc/+/c1524301f72f1764bfe8b8613... ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001) as https://chromium.googlesource.com/external/webrtc/+/c1524301f72f1764bfe8b8613... |
