我想在 iOS 项目中采用 BDD 方法进行单元测试，并且我刚刚意识到可能没有现有的库可以提供 测试间谍 品种。理想情况下，我正在寻找类似于 Mockito、茉莉花，或 RR。
在我花一周的空闲时间编写测试间谍库之前，我想我应该首先在这里提出这个问题。
到目前为止，我已经研究了 OCMock 和 Kiwi，但它们似乎都是传统的 高规格默认模拟框架，需要在排列阶段设置期望断言，在行动阶段之前。显然，这阻碍了我对美丽、DRY、嵌套规范的愿景（我计划这样做）使用 Kiwi 或 雪松）。
I want to take a BDD approach to unit testing in an iOS project, and I just realized that there may not be an existing library that provides test doubles of the test spy variety. Ideally, I'm looking for something similar to Mockito, Jasmine, or RR.
Before I go and spend a week of free time writing a test spy library, I thought I'd pose the question here on SO first.
So far I've looked at OCMock and Kiwi, but they both seem to be of the traditional high-specification-by-default mocking frameworks that require expectation assertions be set in the arrange phase, prior to the act phase. Obviously, this is hampering my vision of beautiful, DRY, nested specs (which I plan on authoring in either Kiwi or Cedar).
发布评论
评论（1）
刚看到这个。
Kiwi现在肯定不会这样做。你是对的，其中的模拟是为表演阶段之前的“标准”安排而构建的。
继续，尽管乍一看，添加间谍功能的基础知识似乎不需要太多的重新设计。到达模拟的每条消息（除了一些重要的实现、保留的选择器之外）都会经过
-[KWMockforwardInvocation:]。本质上，需要修改当前的
-[KWMockforwardInspiration:]以记录/复制通过它的所有调用，而不是现在的操作。这将是允许稍后通过查询记录的调用来验证期望的原始功能。当然，提出一个可读性好的验证形式也不是一件容易的事。间谍/模拟仍然需要预先知道它代表什么类/协议。这样一来，它将能够为发送给它的消息选择器生成有效的方法签名，从而允许运行时转发机制生成将要转发的实际 NSInitation。
我现在正忙于其他事情以在那里实现，但我很乐意回答更多问题或合并任何拉取请求。 HTH。
Just saw this.
Kiwi definitely does not do this now. You are right that the mocks in it are built for a 'standard' arrange prior to act phase.
Moving on, albeit at first glance, it seems that adding the basics for spy functionality would not require too much reengineering. Every message (barring some implementation important, reserved selectors) that gets to a mock goes through
-[KWMock forwardInvocation:].Essentially, the current
-[KWMock forwardInvocation:]would need be modified to record/copy all invocations that pass through it, instead of what it does now. This would be the primitive functionality that would allow expectations to be verified later by querying the recorded invocations. Of course, coming up with a nice readable form for verification isn't trivial either.The spy/mock would still need to know what class/protocol it is standing in for upfront. This is so it will be able to generate valid method signatures for selectors of messages sent to it that allows the runtime forwarding machinery to generate the actual NSInvocation that will be forwarded.
I am preoccupied with other things right now to get an implementation in there, but I'll be happy to answer more questions or merge any pull requests. HTH.