Add mock protocols and view mocks by Grubas7 · Pull Request #19 · Grubas7/AGSnapshotHelper

Grubas7 · 2018-03-13T20:38:40Z

WHAT:

add mock protocols
add view mocks

WHY:

DeviceViewMockable gives us possibility to create objects for specific test case, e.g.

struct Phone_4Inches: DeviceViewMockable {
    var name = "iPhone SE"
    var size = .init(width: 320.0, height: 568.0)
    var layoutMargins = .init(top: 8.0, left: 16.0, bottom: 8.0, right: 16.0)
    ...
}

MockingView gives easy to use View mock container

TO CONSIDER 🤔

maybe MockingView should be called StubingView? Same for protocols.

bielski · 2018-03-21T21:50:23Z

+
+/// A set of properties that provide information about device.
+@objc(AGDeviceMockable)
+public protocol DeviceMockable {


DeviceMockable > MockableDevice?

bielski · 2018-03-21T21:51:28Z

+import Foundation
+import UIKit
+
+public typealias DeviceViewMockable = ViewMockable & DeviceMockable


DeviceViewMockable > MockableDeviceView?

bielski · 2018-03-21T22:00:16Z

@@ -0,0 +1,102 @@
+//
+//  MockingDeviceView.swift


MockingDeviceView or MockedDeviceView? 🧐

Probably you are right.
Mocking and Mockable is good for protocol (https://swift.org/documentation/api-design-guidelines/#protocols-describing-what-is-should-read-as-nouns) and for class probably MockedDeviceView would be better.

Please check also remark: #19 (comment)

aleksandergrzyb

Couple of questions. 👌 Looks really nice.

aleksandergrzyb · 2018-03-27T18:50:34Z

+    var name: String { get set }
+
+    /// Interface orientation to stub.
+    var orientation: UIInterfaceOrientation { get set }


Why UIInterfaceOrientation and not UIUserInterfaceSizeClass? I don't know if combination of UIUserInterfaceIdiom and UIInterfaceOrientation makes sense. UIUserInterfaceIdiom can be UIUserInterfaceIdiomCarPlay, what orientation has this class then?

If we want to support only iOS (iPhone and iPad) we should be more specific than UIUserInterfaceIdiom, maybe create own type.

Why UIInterfaceOrientation and not UIUserInterfaceSizeClass? I don't know if combination of UIUserInterfaceIdiom and UIInterfaceOrientation makes sense.

UIUserInterfaceSizeClasses are defined in ViewMockable protocol.

UIUserInterfaceIdiom can be UIUserInterfaceIdiomCarPlay, what orientation has this class then?

I have never checked interface orientation on CarPlay, but UIInterfaceOrientation has value .unknown so in worst case we could use that.

If we want to support only iOS (iPhone and iPad) we should be more specific than UIUserInterfaceIdiom, maybe create own type.

I don't think we have to limit only to iOS. Car play and tvOS probably can be supported out of box, watchKit requires some work.

aleksandergrzyb · 2018-03-27T18:51:35Z

+
+public typealias DeviceViewMockable = ViewMockable & DeviceMockable
+
+/// View stubing layout defining properties and information about device.


stubing ➡ stubbing (same for other files)

aleksandergrzyb · 2018-03-27T18:56:41Z

+/// Additionally `mockParameters` contains information about mocked device,
+/// which can be use to distinguish interface orientation or device model.
+@objc(AGMockingDeviceView)
+public class MockingDeviceView: UIView {


Maybe DeviceMockView? I find those classes names and protocols pretty confusing.

I'm wondering if Mock/Mocking/Mockable word is correctly used.

mock objects are simulated objects that mimic the behavior of real objects in controlled ways*

And this is a UIView subclass, so it's not a abstract object that try to fulfil our expectation, but it's normal class. The behaviour that I'm trying to achieve is basically inject some read-only data to UIView instance. Maybe more precise name would be StubbedView/StubbedDeviceView?

*https://en.wikipedia.org/wiki/Mock_object

aleksandergrzyb · 2018-03-27T19:02:58Z

+/// Some of layout properties (e.g. `safeAreaInsets`, or `traitCollection`) are read-only,
+/// so this view can be used as container which helps to force custom layout.
+@objc(AGMockingView)
+public class MockingView: UIView {


When one could use MockingView instead of DeviceMockingView? Did you consider making one a subclass of another? It looks like lots of code duplication.

When one could use MockingView instead of DeviceMockingView?
MockingView might be useful for simple testing cases, eg: Developer needs to test some view for larger content size category or custom trait collection.

DeviceMockingView should be used for testing view on specific device eg. iPad (so mockParameters would contains whole set of iPad UI specific values like: size and safe area insets) and additionally values which are useful for describing reference images (eg. orientation [on iPad height > width not always means portrait orientation], device name)

Did you consider making one a subclass of another? It looks like lots of code duplication.

Subclass is impossible because of mockParameters property has different type in MockingView and DeviceMockingView. I reduced trait collection logic.

Subclass is impossible because of mockParameters property has different type in MockingView and DeviceMockingView.

What about making just one subclass of UIView that has two initializers (ViewMockable and DeviceViewMockable)? This kind of generic class would just be one purpose class that would be passed to FBSnapshotVerify(...) method. I think it would make usage a little simpler while preserving all the functionality. What do you think?

Add mock protocols and view mocks

ba0dfff

Grubas7 added this to the 0.1.0 milestone Mar 13, 2018

Grubas7 self-assigned this Mar 13, 2018

Grubas7 requested review from aleksandergrzyb and bielski March 13, 2018 20:38

Change Xcode version

ab493fa

bielski reviewed Mar 27, 2018

View reviewed changes

aleksandergrzyb reviewed Mar 27, 2018

View reviewed changes

Grubas7 added the feature label Apr 11, 2018

Adam Grzegorowski added 2 commits May 7, 2018 22:15

Fix typo

e6daee0

Reduce code repetition

17538ee


		public typealias DeviceViewMockable = ViewMockable & DeviceMockable

		/// View stubing layout defining properties and information about device.

Conversation

Grubas7 commented Mar 13, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

WHAT:

WHY:

TO CONSIDER 🤔

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Grubas7 May 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aleksandergrzyb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Grubas7 May 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Grubas7 May 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Grubas7 commented Mar 13, 2018 •

edited

Loading

Grubas7 May 7, 2018 •

edited

Loading

Grubas7 May 7, 2018 •

edited

Loading

Grubas7 May 7, 2018 •

edited

Loading