Xcode中私有方法的unit testing

我正在尝试玩具项目中的testing驱动开发。 我可以得到为我的类的公共接口工作的testing(虽然我仍然在围栏,因为我正在编写更多的testing代码比在被testing的方法)。

因为我喜欢保持公共接口清洁,所以我倾向于使用很多私有方法。 不过,我仍然想使用这些方法的testing。

由于Cocoa是一种dynamic语言,我仍然可以调用这些私有方法,但是在我的testing中我得到了警告,我的类可能不会对这些方法做出响应(虽然很明显)。 由于我喜欢编译没有警告,这里是我的问题:

  1. 我如何closuresXcode中的这些警告?
  2. 还有什么我可以做的关掉这些警告?
  3. 我在尝试“白盒”testing时做错了什么?

我如何closuresXcode中的这些警告?

别。

还有什么我可以做的关掉这些警告?

别。

我在尝试“白盒”testing时做错了什么?

没有。

解决的办法是将你的私有方法移到它自己头部的类别中。 将这个头文件导入到真实的类和testing用例类的实现文件中。

请记住Objective-C中实际上没有“私有方法”这样的事情,这不仅仅是因为它是一种dynamic语言。 通过devise,Objective-C为ivars提供了可见性修饰符,但不是用于方法的 – 您可以调用任何您喜欢的方法,这并非偶然。

彼得的build议是一个很好的build议。 为了补充他的答案,我使用的一个替代scheme(当我不需要/只需要私有方法的头文件)就是在unit testing文件中声明一个类别 。 (我使用@interface MyClass (Test)作为名称)。这是添加方法的好方法,这些方法在发布代码中会不必要的膨胀,例如访问被testing类可以访问的ivars。 (当使用属性时,这显然不是一个问题。)

我发现这种方法可以很容易地公开和validation内部状态,并且添加只有testing的方法。 例如,在这个unit testing文件中 ,我写了一个用于validation二进制堆的正确性的-isValid方法。 在生产中,这种方法会浪费空间,因为我认为堆是有效的 – 如果我修改代码,在testingunit testing回归时,我只关心它。

看起来像另一个问题有答案: 有没有办法在Xcode压制警告?

虽然拥有私有头文件或定义自己的类别可能是更正确的解决scheme还有另一个非常简单的解决scheme:在调用方法之前将对象强制转换为(id)。

如果您不想在多个源文件中分发您的私有方法实现,那么对Category解决scheme进行改进就是在由您的现有类导入的头文件中定义一个扩展(实质上是一个匿名类别 – 参考Apple文档 ) '执行和相关的unit testing源文件。

使用扩展允许编译器在主@implementation块中不存在私有方法的实现时发出警告。 这个链接很好地说明了这一点。

我在几天前开始使用TDD时,也遇到了同样的问题。 我在“ testing驱动的iOS开发”一书中发现了这个非常有趣的观点:

我经常被问到:“我应该testing一下我的私人方法吗?”还是相关的问题“我应该如何testing我的私人方法?”提问第二个问题的人认为第一个答案是“是”,现在正在寻找为了在testing套件中公开类的私有接口。

我的答案依赖于观察一个微妙的事实:你已经testing了你的私有方法。 通过遵循testing驱动开发中常见的红绿重构方法,您devise了对象的公共API来完成这些对象所需的工作。 通过testing指定的工作,并继续执行testing,确保您没有损坏任何东西,您可以自由组织class级的内部pipe道。

您的私有方法已经过testing,因为您所做的只是您已经进行过testing的重构行为。 在私有方法未经testing或未经过完整testing的情况下,您绝对不应该这样做,因为只有在您看到有机会清理公共方法的实施时才创build它们。 这确保了私有方法的存在只是为了支持在testing期间必须被调用的类,因为它们肯定是从公共方法调用的。

简单的工作。 步骤:1.你有 – (NSString *)getTestString; 在接口Foo的目标m文件中

  1. 在你的unit testing文件中添加一个类别:

    @interface DemoHomeViewController() – (NSString *)getTestString; @结束

然后,做任何你想要的东西。