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.
Mike > On Dec 3, 2015, at 8:03 PM, Tony Parker <anthony.par...@apple.com> wrote: > > Hi Brian, > >> On Dec 3, 2015, at 3:45 PM, Brian Gesiak <modoca...@gmail.com >> <mailto:modoca...@gmail.com>> wrote: >> >> Hello! This is in reference to >> https://github.com/apple/swift-corelibs-xctest/pull/3 >> <https://github.com/apple/swift-corelibs-xctest/pull/3>. That pull request >> contains a commit that attempts to refactor XCTest such that it is more >> "unit-testable”. >> > > Cool, thanks for looking into this area. > >> 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.). >> > > 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? > > 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). > > 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. > > - Tony > >> 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! >> >> 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). >> >> I'd love input on which of these approaches sounds more viable. Other ideas >> are also, of course, welcome! >> >> - Brian Gesiak > > > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
