Howdy, If my immediate goal were to verify private member values at intermediate steps in some process, which is the concept under consideration in the article you provided, I could access their values with a Mirror.
That's not my immediate goal. My immediate goal is to falsify that the property is private. The logic in the article asserts that a member is private, then asserts that because the member is private we do not need to test it. But it fails to provide an automated test that the member is indeed private and remains so. To accomplish that goal without an automated unit test is painstakingly tedious for a human. And as to whether the logic in the article is correct, assuming its assumptions are true, it is still only one kind of testing. Depending on the field it might be called "interface" or "black box" testing, and they rightly call that out. But it would not be considered to be the only kind of testing which needs to be done. -Ben Sent from my iPhone. > On Dec 13, 2016, at 1:35 AM, Jean-Daniel <mail...@xenonium.com> wrote: > > An interesting reading about testing private members: > > https://cocoacasts.com/how-to-unit-test-private-methods-in-swift/ > > >> Le 12 déc. 2016 à 06:10, Derrick Ho via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> It bugs me as well that we can not test private components using XCTest. >> Objective-c never had this problem since privacy doesn't exist. I would like >> to see a version of XCTest that allows us to test every component. >> >> >>> On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> Howdy, >>> I’d like to see how much interest there is for adding these to the >>> XCTest module. If I have missed some pro or con, or missed a technical >>> point, your feedback is welcome before I go to the lengths to draw up a >>> formal proposal. >>> >>> >>> There are several features of Swift which cannot be effectively >>> automated-tested. >>> For instance, when a type or one of its members is private or file private, >>> an outside test suite cannot access it, and the information that the type >>> is private is not included in a Mirror. There are similar concerns for >>> testability with internal, and public access levels. Tests can be written >>> ensuring these access levels are >= some level, but not == or < some level. >>> In other words the very usefulness of these features cannot be tested. >>> >>> Other attributes to be tested in this way are: >>> >>> - Mutability of a member. No automated test can be written which verifies >>> that a function cannot be called on a let struct, or that a property cannot >>> be set at a specific access level. >>> >>> - That a stored property is weak or unowned. >>> >>> - That a class or class member is “final” >>> >>> These are concepts which need to be unit-tested to ensure good design is >>> not broken, but do not need to be included in a release build, so including >>> them in the XCTest framework seems like an appropriate destination. >>> Moreover, the information for all of these features exists in the >>> .swiftmodule files, which are included in test builds, but sometimes >>> stripped for release. >>> >>> Examples: >>> Since these features inherently have to do with testing features which >>> cannot be stated in compiled code, I recommend specifying names with >>> Strings. Here are some examples of what I would like to write in my test >>> code: >>> >>> XCTAssertEqual( >>> Module(named:”SingMusicLayout”)?.type(named:”NoteSetter”)?.property(named:”session”)?.accessLevel, >>> .private) >>> >>> XCTAssertEqual( >>> Module(named:”SingMusicLayout”)?.type(named:”ScaleLayout”)?.method(named:”baselineOffset(for:PitchInterval)->CGFloat”)?.mutable, >>> false) >>> >>> >>> Alternatives: >>> 1. Building an independent .swiftmodule parser in a single Swift >>> module, which can be included in test builds. >>> + Can be distributed independently from Swift sources, >>> requiring 0 buy-in from Swift community >>> + requires a single additional module for the test. >>> - Depends on ever-changing binary interface. >>> : Intractable, not DRY >>> >>> 2. Use existing sourcekitd. >>> + harnesses changes in the compiler’s source code with >>> SourceKit >>> - cannot be run in a test suite without extensive work by >>> user to configure bundles explicitly. >>> Exceptionally poor user experience >>> : sourcekitd XPC architecture only works on macOS >>> >>> 3. Use a standalone tool for tests >>> + harnesses changes in the compiler’s source code with >>> SourceKit >>> + no installation in user’s source code necessary >>> : cannot be effectively run by SPM test infrastructure >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
