[swift-evolution] adding automated-testing of uncompilable features in XCTest
brianaking at gmail.com
Thu Dec 15 07:51:20 CST 2016
Another relatively new option is using Sourcery
(https://github.com/krzysztofzablocki/Sourcery). It sits on top of
SourceKit and provides a Stencil template to generate code. You could
generate code that reflects the visibility of your functions and write
tests that validate the generated code.
I think Mirror types may be able to accommodate this type of testing
in the future, but this may fill the gap for now.
On Thu, Dec 15, 2016 at 1:37 AM, Benjamin Spratling via
swift-evolution <swift-evolution at swift.org> wrote:
> Do you see this working with the package manager as well?
>> On Dec 14, 2016, at 7:42 AM, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
>> The Swift compiler can give you the information that you want.
>> Here is what you can do:
>> Write a Swift source file that creates an instance of the type you want to test and then tries to access each of the private members.
>> Write a shell script to compile this source file i a module with the file the type is defined in. Have it capture all the error messages by redirecting stderr and then count them. If it doesn’t have the right number, have the shell script emit a message that looks like a Swift error message.
>> Install the script in a run script build phase. Now you will get an error every time one of your private properties or methods loses its access modifier.
>> Personally, I wouldn’t bother. Any test to make sure that private members are private requires a separately maintained list of the private members. If somebody isn’t disciplined enough to add the word “private” to the beginning of a definition, they almost certainly aren’t going to bother updating a separate list. And the consequences of omitting “private” are only that the module has visibility of it. That’s not a huge deal.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution