我是Specflow和BDD的忠实粉丝.在各种项目中,它对我来说非常棒.
我还没有解决的一个挑战是以某种方式组织我的特征文件和场景,这使得它易于导航和探索.想象一年后,其他人想要来参加并了解该系统.从哪儿开始？什么是最重要的,什么不重要？功能之间有什么关系？系统是否处理特定方案？作者有没有想过这个问题？
任何人都可以分享一些专注于此的技巧,阅读或工具吗？
在谈论自动化UI测试时,对话总是最终得到UI自动化.这是唯一的选择吗？
我个人不喜欢它的一个主要原因 - 复杂性.它适用于所有类型的应用程序.这种普遍性永远不会免费.UIA引入了另一层抽象和一个相当复杂的API.标准模式是有限的.自定义控件支持需要大量编码.我想知道为什么有人认为这是一个不错的选择？
WPF具有辉煌和非常丰富的抽象,其中UI是视觉元素的分层树.这些元素暴露了许多方法,事件和属性.树支持各种引用方式(例如相对源语法).我们在UIA中放弃了所有这些.为了什么？为了兼容旧式应用和网络？实际上,谁会需要呢？所有行业的杰克都是无所不能的大师.
像Snoop这样的工具可以将自己注入到正在运行的应用程序中并完全控制它.他们可以更改控件属性的值并引发事件.那不够吗？不.您希望您的测试能够像用户一样使用鼠标和键盘与UI进行交互.但这是另一个可以解决的问题.
所以我想知道,有什么我不了解UIA的快乐吗？
我正在构建模块化WPF应用程序.每个屏幕都是一个高度独立和孤立的单元.唯一共享的东西 - shell和一个带有可重用服务的外观接口的公共库(消息总线,持久性,窗口管理等).
由于模块是松散耦合的,因此在单个模块更换时重新测试所有内容是没有意义的.我想只测试改变了什么.如果公共库中有变化 - 应该重新测试所有内容.
从源代码控制diff中,您可以轻松获取已更改的文件列表,从而解决受影响的项目(csproj文件包含要编译的所有文件).您还可以从csproj文件(谁使用它,谁受影响)解析项目依赖项.所有这些信息应足以说明实际需要测试的内容.所以问题听起来可以解决.
有没有人用TeamCity做过这个？有什么建议？我看到有一个Java人员的解决方案:http: //blog.jetbrains.com/teamcity/2012/03/incremental-testing-with-teamcity/
那个.net领域怎么样？