单元测试很棒，但是
我花时间设置了一些单元测试并在 XCode 等中设置了目标，它们对于一些类非常有用。但是：
我想测试一些小的 UI 部分，我不想启动整个应用程序。没有通过/失败的概念：我需要“查看”这些部分，并且我可以创建所有相关类的虚拟实例来执行此操作。我的问题是：如何在 XCode 中进行设置？
我意识到我可以为每个类（或类组）使用另一个 XCode 项目，但这似乎有点麻烦。每个人的另一个目标？
I took the time to set up some Unit Tests and set up the targets in XCode, etc., and they're pretty useful for a few classes. However:
I want to test small UI pieces for which I don't want to launch the entire application. There is no concept of pass/fail: I need to "see" the pieces, and I can make dummy instances of all the relevant classes to do this. My question is: how can I set this up in XCode?
I realize I could use another XCode project for each class (or groups of classes), but that seems a bit cumbersome. Another target for each?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我知道您正在寻找一种不需要功能齐全的应用程序来测试 UI 组件的方法，但 iOS 4.0 中引入的新 UI 自动化工具让您可以做的事情给我留下了深刻的印象。
该工具允许您使用 Javascript 脚本以交互方式测试应用程序的界面，并且不需要检查屏幕上的确切像素值或位置。它使用 VoiceOver 系统中存在的内置辅助功能挂钩来识别组件并与组件交互。
使用这个工具，我已经能够编写测试脚本，在用户与应用程序交互时充分测试我的应用程序，以及针对特定区域并寻找微妙的内存积累的测试。
关于 Instruments 这部分的文档有点稀疏，但我最近教授了一堂涵盖该主题的课程，视频为 在 iTunes U 上免费提供（查找秋季学期的测试课程）。我的课程笔记（VoodooPad 格式）也涵盖了这一点。我还强烈建议观看 WWDC 2010 视频 会议 306 - “使用仪器进行自动化用户界面测试” ”。
I know that you're looking for an approach to testing UI components that doesn't require a fully functional application, but I've been impressed with what the new UI Automation instrument introduced in iOS 4.0 lets you do.
This instrument lets you use Javascript scripts to interactively test your application's interface, and it does so in a way that does not require checking exact pixel values or positions on a screen. It uses the built-in accessibility hooks present in the system for VoiceOver to identify and interact with components.
Using this instrument, I have been able to script tests that fully exercise my application as a user would interact with it, as well as ones that hammer on particular areas and look for subtle memory buildups.
The documentation on this part of Instruments is a little sparse, but I recently taught a class covering the subject for which the video is available on iTunes U for free (look for the Testing class in the Fall semester). My course notes (in VoodooPad format) cover this as well. I also highly recommend watching the WWDC 2010 video session 306 - "Automating User Interface Testing with Instruments".
好吧，即使 GUI 是大型应用程序的一部分，您也不能将显示某个 GUI 的一部分称为测试。您在这里可以做的是创建一个单独的可执行目标并编写一个小工具，该工具可以重用应用程序中的 GUI 组件，并根据输入参数向您显示它们。这将消除对许多不同目标的需要。
如果您仍然坚持使用单元测试，您可以将 GUI 显示一段时间，例如 10 秒。因此，测试用例将一直运行，直到 GUI 关闭或超时结束，并且每个测试最多需要 N 秒来执行。
Well, you cannot call showing a piece of some GUI a testing even if that GUI is a part of a large application. What you can do here is create a separate executable target and write a small tool that reuses GUI components from your application and shows them to you basing on input parameters. This will eliminate the need for many many different targets.
If you still insist on using unit tests, you can show your GUI for some period of time, for example, 10 seconds. So the test case will run until GUI is closed or timeout elapses and each test will take up to N seconds to execute.
这是一个好问题。我认为您实际上不想对那些“视觉确认”使用单元测试。就我个人而言，我通常编写一些小测试应用程序来进行此类测试或开发。我不喜欢同一项目中的单独目标，因此我通常只是在原始项目旁边创建一个测试项目，然后使用相对路径引用这些类和资源。减少混乱。能够在自己的小测试环境中测试更复杂的用户界面元素真是太好了。
This is a good question. I think you actually do not want to use unit tests for those 'visual confirmations'. Personally I usually write little test apps to do this kind of testing or development. I don't like separate targets in the same project so I usually just create a test project next to the original one and then reference those classes and resources using relative paths. Less clutter. And it is really nice to be able to test more complex user interface elements in their own little test environment.
我会采用两级方法进行 UI“单元测试”：
虽然 Cocoa/CocoaTouch 仍然比模型-视图-视图模型范式更接近模型-视图-控制器，但您可以通过以下方式获得大部分可测试性优势：将“视图”分解为“视图模型”和“演示者”视图（请注意，这有点类似于 NSView/NSCell 对；Cocoa 工程师很久以前就有了这个）。如果视图是一个简单的表示层，那么您可以通过对“视图模型”进行单元测试来测试视图的行为。
要测试视图的绘制/渲染，您必须进行人工测试或基于渲染/像素的测试。 Google 的 Mac 版 Toolbox 提供了多种用于逐像素处理的工具渲染的 NSViews、CALayers、UIViews 等的比较。我为核心编写了一个工具绘制项目，以便更轻松地处理测试失败并将参考文件合并回单元测试包。
I would take a two-level approach to UI "unit testing":
lthough Cocoa/CocoaTouch are still closer to the Model-View-Controller than the Model-View-ViewModel paradigm, you can gain much of the testability advantage by breaking your "View" into a "view model" and a "presenter" view (note that this is somewhat along the lines of the NSView/NSCell pair; Cocoa engineers had this one a long time ago). If the view is a simple presentation layer, than you can test behavior of the view by unit testing the "view model".
To test the drawing/rendering of your views, you will have to either do human testing or do rendering/pixel-based tests. Google's Toolbox for Mac has several tools for doing pixel-by-pixel comparison of rendered NSViews, CALayers, UIViews, etc. I've written a tool for the Core Plot project to make dealing with the test failures and merging the reference files back into your unit test bundle a little easier.