<div dir="ltr"><div>Hi Benjamin,<br></div><div><br></div><div>I think your proposal is interesting, and you're certainly right: XCTest has no way to test accessibility levels, or the other attributes you mention. However, I wonder, what do you hope to achieve by adding an automated test for accessibility levels?</div><div><br></div><div>Maybe your goal is to verify the accessibility level is what you think it is. However, in my experience, accessibility levels are fairly straightforward: if I specify a variable is 'public', it's public. If I specify it to be 'fileprivate', it's private to the file. I could write an automated test to verify the accessibility level, but the test would provide me with very little value.</div><div><br></div><div>Maybe your goal is to ensure that other programmers don't accidentally change the accessibility levels. Again, I think because they're straightforward, I don't think there's much danger there.</div><div><br></div><div>To me, tests for accessibility would be redundant. It would be like adding a test to verify that my struct 'Foo' has a member named 'bar'. If I ever decided to rename 'Foo.bar', I would have to update the test. But I would never "accidentally" rename 'Foo.bar' -- if I changed the name, it's because I modified the code for that purpose. A test adds overhead, but no benefit.</div><div><br></div><div>I feel the same about the 'mutating', 'weak', 'unowned', and 'final'.</div><div><br></div><div>It's definitely subjective, though. You might feel that the tests I describe above are valuable, and you're entitled to that opinion.</div><div><br></div><div>If you'd still like to pursue this idea, I think your Swift Evolution proposal would benefit from research on how other languages and testing frameworks approach this problem. How do C++ programmers test whether an attribute is private? How do Java developers test that a class is final? What about Rust or Go?</div><div><br></div><div>- Brian Gesiak</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 12, 2016 at 12:10 AM, Derrick Ho via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div class="HOEnZb"><div class="h5"><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Howdy,<br class="m_-6068798440708443892gmail_msg">
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.<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
There are several features of Swift which cannot be effectively automated-tested.<br class="m_-6068798440708443892gmail_msg">
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.<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
Other attributes to be tested in this way are:<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
- 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.<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
- That a stored property is weak or unowned.<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
- That a class or class member is “final”<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
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.<br class="m_-6068798440708443892gmail_msg">
Moreover, the information for all of these features exists in the .swiftmodule files, which are included in test builds, but sometimes stripped for release.<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
Examples:<br class="m_-6068798440708443892gmail_msg">
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:<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
XCTAssertEqual( Module(named:”SingMusicLayout”<wbr>)?.type(named:”NoteSetter”)?.<wbr>property(named:”session”)?.<wbr>accessLevel, .private)<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
XCTAssertEqual( Module(named:”SingMusicLayout”<wbr>)?.type(named:”ScaleLayout”)?.<wbr>method(named:”baselineOffset(<wbr>for:PitchInterval)->CGFloat”)?<wbr>.mutable, false)<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
Alternatives:<br class="m_-6068798440708443892gmail_msg">
1. Building an independent .swiftmodule parser in a single Swift module, which can be included in test builds.<br class="m_-6068798440708443892gmail_msg">
+ Can be distributed independently from Swift sources, requiring 0 buy-in from Swift community<br class="m_-6068798440708443892gmail_msg">
+ requires a single additional module for the test.<br class="m_-6068798440708443892gmail_msg">
- Depends on ever-changing binary interface.<br class="m_-6068798440708443892gmail_msg">
: Intractable, not DRY<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
2. Use existing sourcekitd.<br class="m_-6068798440708443892gmail_msg">
+ harnesses changes in the compiler’s source code with SourceKit<br class="m_-6068798440708443892gmail_msg">
- cannot be run in a test suite without extensive work by user to configure bundles explicitly.<br class="m_-6068798440708443892gmail_msg">
Exceptionally poor user experience<br class="m_-6068798440708443892gmail_msg">
: sourcekitd XPC architecture only works on macOS<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
3. Use a standalone tool for tests<br class="m_-6068798440708443892gmail_msg">
+ harnesses changes in the compiler’s source code with SourceKit<br class="m_-6068798440708443892gmail_msg">
+ no installation in user’s source code necessary<br class="m_-6068798440708443892gmail_msg">
: cannot be effectively run by SPM test infrastructure<br class="m_-6068798440708443892gmail_msg">
<br class="m_-6068798440708443892gmail_msg">
______________________________<wbr>_________________<br class="m_-6068798440708443892gmail_msg">
swift-evolution mailing list<br class="m_-6068798440708443892gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_-6068798440708443892gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-6068798440708443892gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-6068798440708443892gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_-6068798440708443892gmail_msg">
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>