敏捷方式：集成测试与功能测试或两者兼而有之？
我所在的办公室已经从事敏捷工作一段时间了。 我们使用 Scrum 进行项目管理，并融入 XP 的工程实践。 它运作良好，我们不断吸取教训并完善我们的流程。
我想向您介绍我们通常的测试做法，并获取有关如何改进的反馈：
TDD：第一道防线 我们对单元测试非常虔诚，我想说我们的开发人员也有足够的经验来编写全面的测试，并始终将 SUT 与模拟隔离。
集成测试 对于我们的使用来说，集成测试基本上与单元测试相同，只是不使用模拟。 这往往会发现一些单元测试中漏掉的问题。 这些测试往往难以阅读，因为它们通常涉及规范框架的 before_each 和 after_each 部分中的大量工作，因为系统必须经常达到某种状态为了使测试有意义。
功能测试 我们通常以结构化但手动的方式执行此操作。 我们已经使用了 Selenium 和 Windmill，它们很酷，但对我们来说至少还没有完全实现。
我想听听其他人是如何做事的。 您认为如果集成测试或功能测试做得足够好，其他测试就可以被忽略吗？
I work in an office which has been doing Agile for a while now. We use Scrum for project management and mix in the engineering practices of XP. It works well and we are constantly learning lessons and refining our process.
I would like to tell you about our usual practices for testing and get feedback on how this could be improved:
TDD: First Line of Defense
We are quite religious about unit testing and I would say our developers are also experienced enough to write comprehensive tests and always isolate the SUT with mocks.
Integration Tests
For our use, integration tests are basically the same as the unit tests just without using the mocks. This tends to catch a few issues which slipped through the unit tests. These tests tend to be difficult to read as they usually involve a lot or work in the before_each and after_each sections of the spec framework as the system has to often reach a certain state in order for the tests to be meaningful.
Functional Testing
We usually do this in a structured, but manual fashion. We have played with Selenium and Windmill, which are cool, but for us at least not quite there yet.
I would like to hear how anyone else is doing things. Do you think that if Integration Tests or Functional Testing are being done well enough the other can be disregarded?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
单元、集成和功能测试虽然执行相同的代码，但从不同的角度对其进行攻击。 正是这些观点产生了影响，如果你要放弃一种类型的测试，那么某些东西可能会从那个角度发挥作用。
此外，单元测试实际上并不是要测试代码，尤其是当您正在练习 TDD 时。 TDD 的过程可以帮助您更好地设计代码，最后你会得到一套测试的额外好处。
您没有提到您是否正在运行持续集成服务器。 我强烈建议设置一个（Hudson 很容易设置）。 然后，您可以针对代码的每次签入运行集成和功能测试。
Unit, integration and functional testing, though exercising the same code, are attacking it from different perspectives. It's those perspectives that make the difference, if you were to drop one type of testing then something could work its way in from that angle.
Also, unit testing isn't really about testing your code, especially if you are practising TDD. The process of TDD helps you design your code better, you just get the added bonus of a suite of tests at the end of it.
You haven't mentioned whether you have a continuous integration server running. I would strongly recommend setting one up (Hudson is easy to set up). Then you can have your integration and functional tests run against every check in of the code.
我想说（这只是一个观点问题）您的功能测试是您的真实测试。 即那些实际模拟应用程序实际使用情况的测试。 因此，无论如何，永远不要摆脱它们。
听起来你的系统运行得不错。 如果你没有什么可失去的，就保留一切。
I would say (and this is just a matter of opinion) that your Functional tests are your true tests. Ie those tests that actually simulate real-life usage of your application. For this reason, never get rid of them, no matter what.
It sounds like you have a decent system going. Keep it all if you have nothing to lose.
我们的经验是，一套可靠的硒测试实际上很好地总结了客户对质量的期望。 因此，本质上我们一直在进行这样的讨论：如果编写硒测试与编写单元测试一样简单，我们应该减少对单元测试的关注。
如果某处存在错误但不会对应用程序产生任何影响，谁会真正在乎呢？ 但现实生活中总是存在一些复杂的问题； 您确定您的功能测试捕获了正确的场景吗？ 可能存在由其他系统引起的潜在复杂性，这些复杂性在应用程序的行为中不直接可见。
实际上，一旦您解决了最初的问题，编写 selenium 测试（使用适当的编程语言，而不是 selenese）确实会变得非常简单和有趣。 但我们还不愿意放弃我们的单元测试......
We have experienced that a solid set of selenium tests actually sums up what the customer expects of quality really well. So, in essence we've been having this discussion: If writing selenium tests was as easy as writing unit tests we should focus less on unit tests.
And if there is a bug somewhere that does not have any consequence in the application, who really cares? But there's always the issues surrounding real-life complexities; are you sure your functional tests are capturing the correct scenarios ? There may be underlying complexities caused by other systems that are not directly visible in the behavior of the application.
In reality, writing selenium tests (using a proper programming language, not selenese) does get really simple and fun once you drill through the initial problems. But we're not willing to give up our unit tests quite yet....
单元测试、集成测试和功能测试都有不同的目的。 您不应该仅仅因为其他的运行可靠性很高就丢弃其中一个。
Unit testing, integration testing and functional testing all serve different purposes. You should not discard one just because the others are running at a high level of reliability.
在我当前的客户中，我们并没有真正区分单元测试和集成测试。 业务实体如此依赖于底层数据层（使用自主开发的 ORM 框架），以至于实际上我们很少或根本没有真正的单元测试。
构建服务器在 Team Build 中通过持续集成 (CI) 进行设置，为了避免因缓慢的测试而陷入困境（完整的测试套件需要一个多小时才能在服务器上运行），我们将测试分为“慢速”每天运行两次的测试和作为持续集成的一部分运行的“快速”测试。 通过在测试方法上设置属性，构建服务器可以区分两者之间的区别。
一般来说，“慢”测试是指任何需要进行数据访问、使用网络服务或类似的测试。 按照惯例，这些将被视为集成测试或功能测试。 例如：CRUD 测试、需要使用一组对象的业务验证规则测试等。
“快速”测试更像是单元测试，您可以在其中合理地隔离单个对象的状态和行为以进行测试。
我认为任何在十分之一秒或更短时间内运行的测试都是“快”的。 其他任何东西都很慢，可能不应该作为 CI 的一部分运行。
我同意您不应该太关注作为开发一部分使用的测试的“风格”（当然，将验收标准表示为测试是例外）。 个体开发人员应该根据自己的判断来决定哪种类型的测试最适合他们的代码。 坚持对业务实体进行单元测试可能不会揭示 CRUD 测试会出现的错误，等等......
At my current client we don't really separate between unit-tests and integration-tests. The business entities are so dependent on the underlying data-layer (using a homegrown ORM framework) that in effect we have little or no true unit-tests.
The build server is set up with continous integration (CI) in Team Build and to keep this from bogging too much with slow tests (the full test suite takes over an hour to run on the server) we have separated the tests into "slow" tests that gets run twice a day and "fast" tests that get run as part of continous integration. By setting an attribute on the test-method the build-server can tell the difference between the two.
In general, "slow" tests are any that needs to do data-access, use web-services or similar. These would be considered integration tests or functional tests by common convention. Examples are: CRUD-tests, business validation rule tests that need a set of objects to work with, etc.
"Fast" tests are more like unit-tests, where you can reasonably isolate a single object's state and behavior for the test.
I would consider any test that run in tenths of a second or less to be "fast". Anything else is slow and probably shouldn't be run as part of CI.
I agree that you should not get too hung up on the "flavor" of test you use as part of development (expressing acceptance criteria as tests is the exception of course). The individual developer should use their judgement in deciding what type of tests best suit their code. Insisting on unit-tests for a business entity might not reveal the faults a CRUD-test would and so on...
我将单元测试比作确保段落中的单词拼写正确。 功能测试就像确保该段落有意义，并且在其所在的文档中流畅运行。
I liken unit testing as making sure the words in a paragraph are spelled correctly. Functional testing is like making sure the paragraph makes sense, and flows well within the document it's living within.
我倾向于不区分 TDD 中的各种测试风格。 对我来说，TDD 是测试驱动开发，而不是单元测试驱动开发。 所以我的 TDD 实践结合了单元测试、集成测试、功能和验收测试。 这导致某些组件被某些类型的测试覆盖，而其他组件则以非常务实的方式被其他类型的测试覆盖。
我问了一个问题 关于这种实践的相关性，简短的回答是，在实践中，区分是在每次构建时自动运行的快速/简单测试和运行频率较低的慢速/复杂测试之间。
I tend not to separate various flavours of testing in TDD. For me TDD is Test-Driven Development, not Unit Test-Driven Development. So my TDD practice combines unit tests, integration tests, functional and acceptance tests. This results in some components being covered by certain types of tests and others components being covered by other types of tests in a very pragmatic fashion.
I have asked a question about the relevance of this practice and the short answer was that in practice the separation is between fast/simple tests run automatically at every build and slow/complex tests run less often.
我的公司进行功能测试，但不进行单元或集成测试。 我试图鼓励我们采用它们，我认为它们鼓励更好的设计并更快地表明一切都很好。 如果进行功能测试，是否需要单元测试？
My company does functional testing but not unit or integration testing. Im trying to encourage we adopt them, i see them as encouraging better design and a faster indication that all is well. Do you need unit tests if you do functional testing?
我真的很喜欢 Gojko Adzic 的“面子测试”概念，以此来确定通过 UI 测试的内容：http://gojko.net/2007/09/25/ effective-user-interface-testing/
I really like Gojko Adzic's concept of a "face saving test" as a way to determine what you test via the UI: http://gojko.net/2007/09/25/effective-user-interface-testing/
你应该做所有这些，因为单元、集成和功能测试都有不同的目的。
对我来说重要的一点是，编写测试的方式非常重要，TDD 还不够，BDD（行为驱动开发）提供了一个很好的方法......
You should do all of them because unit,integration and functional testing all serve different purposes.
Belongs to me an important point is that the way write test is very important and TDD is not enought, BDD (behavior driven development) give a good approach...