Updated Course: Testing in iOS

[vegetarianzombie]

Learn the basics of constructing unit tests and UI tests, and how to incorporate them into your app.

---

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/251-updated-course-testing-in-ios

[gargoyle]

Do you have suggestions for testing private functions? The @testable let us access all the ‘internal’ stuff, but not ‘private’. For example, the class might have a private method that implements some very complex algorithm. I of course want to unit test that algorithm but I can’t access it. It stinks that I end up making methods “internal” just so I can test them when I really don’t want them accessible by any other class.

[fahim]

@gargoyle

Do you have suggestions for testing private functions? The @testable let us access all the ‘internal’ stuff, but not ‘private’.

One of the reasons for introducing the internal access modifier in Swift, if I’m not mistaken, was to allow testing of methods which were previously marked private. So your solution for testing private methods would be to mark them as internal

Since internal allows access from within only the current app or module, I’m not sure why it would be an issue to mark items as internal instead of private?

[gargoyle]

They’re really very different things. internal makes it available to the entire project, which is definitely not what is wanted here. The method should be private so that nothing accidentally calls that or thinks it’s available for internal use.

[fahim]

@gargoyle

They’re really very different things. internal makes it available to the entire project, which is definitely not what is wanted here. The method should be private so that nothing accidentally calls that or thinks it’s available for internal use.

I agree that they are different - that’s why you have two different attributes But as a developer, I see private working differently than you do. I don’t think in terms of “accidental” use. I should know what I’m accessing and not accessing in my own codebase. So I’m mostly concerned with how others access or aren’t able to access certain properties or methods in my classes. So, for general work, private and internal work just fine to fence out relevant bits for testing (from within my own project) vs. not allowing access to some items at all from external libraries/code.

As far as what you are looking for goes, to test private methods using unit testing, I’m afraid that that’s not possible and goes against the intents of the private attribute

[gargoyle]

@fahim

I should know what I’m accessing and not accessing in my own codebase.

That’s a great assumption, as long as it’s not a team of people working on it.

But you clearly answered my question. If I want to be able to test it, then I have to make it internal. Thanks.