敏捷方式:集成测试与功能测试或两者兼而有之？

我在办公室工作,现在已经做了一段时间的敏捷.我们使用Scrum进行项目管理,并混合使用XP的工程实践.它运作良好,我们不断学习课程和完善我们的过程.

我想告诉您我们通常的测试实践,并获得有关如何改进的反馈:

TDD:第一道防线 我们对单元测试非常虔诚,我会说我们的开发人员也经验丰富,可以编写全面的测试,并始终将SUT与模拟隔离开来.

集成测试 对于我们的使用,集成测试基本上与不使用模拟的单元测试相同.这往往会抓住一些问题,这些问题在单元测试中滑落.这些测试往往是难以阅读,因为它们通常涉及在大量或工作before_each和after_each规范框架的部分作为系统,以便为测试是有意义的经常达到一定的状态.

功能测试 我们通常以结构化但手动的方式执行此操作.我们玩过Selenium和Windmill很酷,但对我们来说至少还没有.

我想知道其他人是怎么做的.你是否认为如果集成测试或功能测试做得好,另一个可以被忽视？

单元,集成和功能测试虽然运用相同的代码,但却从不同的角度进行攻击.正是这些观点产生了不同,如果您放弃一种类型的测试,那么从这个角度来看,某些东西可以起作用.

此外,单元测试并不是关于测试代码,特别是如果您正在练习TDD.TDD的过程可以帮助您更好地设计代码,最后您可以获得一系列测试的额外奖励.

您尚未提及是否正在运行持续集成服务器.我强烈建议设置一个(Hudson很容易设置).然后,您可以针对代码的每次签入运行集成和功能测试.

我们经历过一系列坚实的硒测试实际上总结了客户对质量的期望.所以,本质上我们一直在讨论:如果编写硒测试就像编写单元测试一样简单,我们应该更少关注单元测试.

如果有是一个错误的地方,没有在应用程序中的任何后果,谁真正在乎呢？但总是存在围绕现实生活复杂性的问题; 你确定你的功能测试正在捕捉正确的场景吗？可能存在由应用程序行为中不直接可见的其他系统引起的潜在复杂性.

实际上,一旦你钻研了最初的问题,编写硒测试(使用适当的编程语言,而不是selenese)确实变得非常简单和有趣.但是我们还不愿意放弃我们的单元测试....