<div dir="ltr"><div>I think this is something really valuable in multiple cases and I'm particularly interested in having this to improve the usage of inversion of control. However, I wonder if this is possible due the strong static typing from Swift or if it may not reduce the safety of the language.</div><div><br></div><div>But I found the current limitations regarding this matter very educational actually, because enforces us to really design our code using interfaces instead of concrete implementations which aligns with one of the SOLID principles, Dependency inversion.</div><div><br></div><div>In your example for example, by adopting this principles we should not rely in the instance of UIApplication directly but instead define an interface that represents this intention of opening an URL like you have suggested. But I think this is valuable not only because it makes the code testable but specially because we can achieve an abstraction of UIApplication class itself making it reusable. Suppose that you want to reuse this code in another architecture, e.g. Linux, having this abstraction you will not need to adapt your code but instead only provide a concrete implementation for your current target, Linux, iOS or even unit-tests.</div><div><br></div><div>- David</div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-18 22:09 GMT+00:00 Gergely Orosz via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Also consider alternatives to the use cases you described—mocking and data modeling can also be accomplished by compile-time code generation, and by features like type providers that supply external type information to the compiler. Runtime reflection is definitely useful in many cases, but compile-time approaches are likely to be easier to verify and maintain, faster, and more secure.<br></div><span><font color="#888888"><div><br></div><div>-Joe</div><br></font></span></div></blockquote></div></span>I am aware of the current alternative of specifying dependencies to be mocked complile time. However I see a major issue on how protocols need to be added that are only used by the test code - yet they ship as part of the production code.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For example consider a method that opens an external URL from the application by invoking the UIApplication.sharedApplication().openUrl(...) method. In order to write a unit test to verify this call is being made a new protocol needs to be specified that defines the openUrl() method, as UIApplication does not implement any protocols (lets call this UIApplicationProtocol). Then via an extension UIApplication needs to inherit this UIApplicationProtocol, and the original code can be changed to use a UIApplicationProtocol dependency when invoking openUrl(). </div><div class="gmail_extra"><br></div><div class="gmail_extra">My main issue is that UIApplicatipnProtocol is not used anywhere in the production code, but purely added to enable testing. The same applies for any developer specified class - to enable testing often a matching protocol needs to be specified, even if this protocol is not needed or used by the production code.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If in order to be able to unit test production code, that code needs to ship with test-only code, then I do feel that indicates that the language is not very "test friendly". In Objective C one can write production code as simple as intended and by replacing methods runtime do all the testing they want in their test project. Of course there is a performance hit - however the vision of Swift is to get all the benefits of Objective C without having to worry about performance</div><div class="gmail_extra"><br></div><div class="gmail_extra">Being able to opt in to reflection would be a good start - this would give developers an option to choose whether or not to sacrifice any performance for the sake of a bit cleaner code (no test-only protocols).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Howeve opt-in reflection will still not solve how to unit test calls to foundation classes like in my example - will the recommendation be for developers to specify their own extension protocols for these foundation class methods they want to test? Or would it make sense for all foundation classes to also implement a protocol to give more support for this kind of unit testing?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also for test code performance is much less of an issue - would it be feasible to apply different restrictions to reflection for test projects? In a similar way to how the @testable declaration sidesteps some of the security limitations of non-public members, could @testable also be used to relax reflection restrictions for the imported code?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra"><br></div><div class="gmail_extra"> Gergely</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=UZ-2Fw3Bg8EOda-2F-2BSazO07kQ0r5nBosEb9Ga0vHTFIm-2BXXns-2Bu6WmvtprGTc-2BY9k6OMxGDIerBkz2dvut4m-2FRKbiZqiUZyYR2ST82NykIpsfl5um7y0OVlWywjUoXVO2SUnj8U6-2BSvEJ-2FFzk-2F0uvt6PMF2Hq5-2FNapoo7qMsh-2B1gcTXLQsS-2Fg-2B3TDLK3y0ptj83K4VSpgiUhJwHmYNVsTDwBGaYZiUH21FAhc-2Bmw36w4LI-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>