<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Honestly, we’re still trying to figure out how best to handle the balance between work that we are planning and carrying out in the Xcode version of XCTest under our normal development process and engagement of the open source community that is developing around the corelibs version of XCTest.<div class=""><br class=""></div><div class="">We would like to do as much as we can in the open. There are several competing tensions we’re trying to balance though.</div><div class=""><br class=""></div><div class="">- We need to be cognizant of our own release schedules and targets for the work we’re doing to extend the features and IDE integration of XCTest. Unlike the Swift language itself, the things we may be adding to corelibs XCTest are not the whole story. We are adding these things to Xcode’s XCTest as well and that work also must be accommodated. The fact that the corelibs XCTest is not the same code base as Xcode’s XCTest is going to have implications for how development on this project goes that I think we’re all still trying to figure out.</div><div class=""><br class=""></div><div class="">- Especially when the changes we’re making are specific to Swift or even highly relevant to Swift, we want to be able to allow the corelibs XCTest to run a little ahead of Xcode’s XCTest, but only where we’re committed to closing the gap in a known and relatively short time frame. So, for the moment, we’ve actually added this API to corelibs XCTest even though the corresponding API has not yet showed up in Xcode’s XCTest (at least not in a shipping Xcode yet… since this particular change is implemented in the overlay for Xcode’s XCTest, it should be available ahead of official release to those using toolchains from the swift project.)</div><div class=""><br class=""></div><div class="">- And, at times there will be cases where we’re unable to do certain XCTest work in the open (not in this case, but it will come up in the future) and there are also times when we will decide to do work in Xcode’s XCTest that is not simultaneously brought to corelibs XCTest by Apple.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In this particular case, I’d say the main issue that caused us to take a more abbreviated path to getting this stuff in was scheduling (which is an area that I cannot go into specifics about). As well there’s an aspect of us still trying to get used to the idea of how this will all work. So, we decided to dip our toes in, at least, by pushing the proposal out and getting some feedback, but we did not treat it fully as a formal proposal and review process.</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">Some of this is perhaps a bit vague, I realize, but hopefully it gives at least a bit of insight into the decision…</div><div class=""><br class=""></div><div class="">Mike</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 5:20 PM, Brian Gesiak via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Loving those commits! Especially the corresponding tests :)<br class=""><br class="">Can you explain the decision to not go through the review process? I think it's a prudent decision and I'm supportive of it, but I was under the impression that additional APIs should be proposed and reviewed. Is the rationale that swift-corelibs-xctest is too immature to justify going through proposals?<div class=""><div class=""><br class=""></div><div class="">- Brian Gesiak<br class=""><div class=""><br class=""></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 13, 2016 at 4:52 PM, Chris Hanson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Thanks, everyone, for all of the feedback.<div class=""><br class=""></div><div class="">I sent this proposal out as more of a “heads up” that we were planning to make these changes and get feedback in advance of that, so we won’t be taking this through the full proposal process. That said, here’s what we’re going to be doing:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">1. We’re going to let test methods throw, and treat those as unexpected failures, as planned.</div><div class=""><br class=""></div><div class="">2. We’re going to let test assertion expressions throw, and treat those as unexpected failures, as planned. We recognize that this will result in slightly different style in tests versus in regular code, but the convenience and reduction in boilerplate makes this worthwhile.</div><div class=""><br class=""></div><div class="">3. We’re going to add the <font face="Menlo" class=""><span style="font-size:11px" class="">XCTAssertThrowsError</span></font> assertion, incorporating Kevin Ballard’s suggestion for how to avoid the “<font face="Menlo" style="font-size:11px" class="">_ = blah()</font>” in its expression.</div><div class=""><br class=""></div><div class="">4. We’re <i class="">not</i> going to add the ability for <font face="Menlo" class=""><span style="font-size:11px" class="">XCTAssertThrowsError</span></font> to check that a specific error was thrown. This could definitely be useful but would require the function to take an <font face="Menlo" class=""><span style="font-size:11px" class="">ErrorType</span></font> instance that also conforms to <font face="Menlo" class=""><span style="font-size:11px" class="">Equatable</span></font>. We need to think about that some more before making such a change. Fortunately this sort of addition will be straightforward to put in via an overload or default argument, so if we choose to do it later, it shouldn’t break any code that starts to adopt <font face="Menlo" class=""><span style="font-size:11px" class="">XCTAssertThrowsError</span></font>.</div></blockquote><div class=""><br class=""></div><div class="">We’re going to start landing these changes today, so thanks again for all of your attention and feedback!</div><div class=""><br class=""></div><div class=""> -- Chris</div><div class=""><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RwYb2GKd-2F4OO18dA6Iy-2B3LrStHfLgivaBZlWDE47E-2FK-2FtzQmQ-2FdfVC5GCL-2B2hzJcKbithr0Jb61cYj1d2fxQ5dbcvlwhbMR7c5-2BzxtUX3GqWBrulVXLlLGTkyiaa6S6mIssZNfUlPjyjtszWchjhV5NcVLAJQJBWqiRVyaj5qZJ0a4CDKS-2FrPWqoK-2FAMAHgMV9z5C4shwtZSakcO9-2BPDIqD2as1lAlbjzKJC3inICdU-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=qCTjHmennvWckZUgqTp8Fd-2Fuh5ocG9KEhDc-2FQVY-2FS9ALFPP4qRbQ5i1NLUIt-2BKClRKWQajgNSUqVxeuiLQ2Iad92KtgREmXLLZTDY3W6oIpX0JaLQm3PpcV-2BKtpfJD2RjymncV0azZr-2FncXsiwQela36fdp4lKipEI9xua-2FNEtW9jU-2BkA0aiwAUSDvH15cMcCN6YYef-2FryJn9XljObyOTk-2BCMfEp-2BdajB7bj2-2BwyPps-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>