Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

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

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Howdy, Do you see this working with the package manager as well? -Ben > On Dec 14, 2016, at 7:42 AM, Jeremy Pereira > wrote: > > The Swift compiler can give you the information that you want. > > Here is what you can do: > > Write a Swift source file

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Use protocols {get} Can be used for let {get set} Can be used for var On Thu, Dec 15, 2016 at 1:16 AM Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > Howdy, > Thanks, I’ll consider this as an alternative. > I don’t see that this solves the issues of

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Howdy, Thanks, I’ll consider this as an alternative. I don’t see that this solves the issues of whether a property on a class is let, however. -Ben > On Dec 14, 2016, at 11:41 PM, Derrick Ho wrote: > > You might be able to ensure access modifiers by using

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

You might be able to ensure access modifiers by using protocols. If you want to ensure that a class has a property called foo that is private you can make a private protocol that specifies a private property called foo. This isn't a XCTest but it is a compile time check. If a programmer tries to

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Just to share my feelings and ideas. It seems to me it would be better addressed by code review. Among other things it would start the conversation about what should be made public, what should not, and why. On the automated part, there could be tools detecting changes to the public APIs (and

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Derrick and Jean-Daniel, it's my understanding that Benjamin is proposing adding a way *to test that members are private/internal/public*, not a way to access private members in tests. If you'd like to discuss what you're describing, it's probably best to start a separate email thread. - Brian

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

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 > a écrit : > > It

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

> On Dec 12, 2016, at 2:17 AM, Rien wrote: > That is a very elusive goal. > The best way to do this is through hiring competent people… If nothing else, I would hope that we can agree that enabling the testing of all our design choices is a goal. Towards that, my goal

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

> On 12 Dec 2016, at 07:23, Benjamin Spratling via swift-evolution > wrote: > > > > -Ben > > Sent from my iPhone. > >> On Dec 11, 2016, at 11:43 PM, Brian Gesiak wrote: > >> Maybe your goal is to ensure that other programmers don't

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

-Ben Sent from my iPhone. > On Dec 11, 2016, at 11:43 PM, Brian Gesiak wrote: > 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

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Hi Benjamin, 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? Maybe your goal is to verify

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

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] adding automated-testing of uncompilable features in XCTest

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