<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="">One possible direction to consider which would be more consistent with our goals this year for API-compatibility would be to look into implementing XCTestObserver.<div class=""><br class=""></div><div class="">Mike</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 8:03 PM, Tony Parker <<a href="mailto:anthony.parker@apple.com" class="">anthony.parker@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Brian,<div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 3:45 PM, Brian Gesiak <<a href="mailto:modocache@gmail.com" class="">modocache@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello! This is in reference to <a href="https://github.com/apple/swift-corelibs-xctest/pull/3" class="">https://github.com/apple/swift-corelibs-xctest/pull/3</a>. That pull request contains a commit that attempts to refactor XCTest such that it is more "unit-testable”.<br class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Cool, thanks for looking into this area.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">To do so, it gives XCTMain an additional parameter: a list of objects conforming to the Reporter protocol. I think of this as a minimal, corelibs equivalent to Apple's XCTest's XCTestObserver.h. I say "minimal" because Reporter only defines Reporter.log(), whereas XCTestObserver has one method for each kind of test event (started, failed, finished, etc.).<br class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Do you think it’d be possible to split out the idea of adding this new API to XCTest from getting some tests for XCTest itself?</div><div class=""><br class=""></div><div class="">The reason I’m asking is that (like Foundation and dispatch), we’re trying to keep the API surface of this XCTest very similar to the one that ships today with Xcode. This will help developers who need to integrate their cross-platform tests into suites that include features that Obj-C XCTest has that we will probably not add to the Swift one (e.g., UI testing).</div><div class=""><br class=""></div><div class="">We made a concession to language limitations with the XCTMain function, because there is no way to dynamically discover all of the test cases. I’d really like to get rid of it in the long term in favor of something else; maybe a decoration like @testable that we could find automatically.</div><div class=""><br class=""></div><div class="">- Tony</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">These reporters are, for now, storied in a global array. In the future, I'd like to discuss moving XCTest to a model in which all tests are (optionally) run in sub-processes, each of which may (optionally) run in parallel. This global array most certainly won't work for such a change, but for now, I simply want to have regression tests on the project. It's hard to send pull requests without knowing everything still works!<br class=""><br class="">Besides this approach, which modifies XCTest in order to test it, it may be more prudent to add tests *without* changing XCTest at all. To do so, I could add tests that run programs that call XCTMain(), then verify what's printed to stdout. This could be done using a Python script (which would go well with the build script, also in Python).<br class=""><br class="">I'd love input on which of these approaches sounds more viable. Other ideas are also, of course, welcome!<br class=""><br class="">- Brian Gesiak</div>
</div></blockquote><br class=""></div><div class=""><div class=""><br class=""></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=qCTjHmennvWckZUgqTp8Fd-2Fuh5ocG9KEhDc-2FQVY-2FS9D4KVOaaHGBaAp8fq6szqoURIsKdfAqqtF91QB8Wkq2hJv-2BlTFSkRct-2BlFoHzKDY-2Bjw5-2BaBXLIT4UdSG0UZCd7QQMwZZJ4pycJmJ-2FA1s-2BWnHV0fa4a00nHah-2FKTXjppqd228aMR1-2FgnCQOSjMqQViw39JU0HeavY79iLCX-2B7EDIDO5LZebRqGwUWt7ZJ1sJ2VU-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="">
</div>
_______________________________________________<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></body></html>