Questions tagged «integration-tests»

集成测试是软件测试中的阶段，在该阶段中，将各个软件模块组合在一起并作为一个整体进行测试。不需要模拟或存根；一切都经过生产测试。

11
（数据库）集成测试不好吗？
有人坚持认为集成测试是种种种错误和错误的方法 -一切都必须经过单元测试，这意味着您必须模拟依赖项；由于种种原因，我并不总是喜欢这种选择。 我发现在某些情况下，单元测试根本无法证明任何事情。 让我们以以下（简单，幼稚的）存储库实现（在PHP中）为例： class ProductRepository { private $db; public function __construct(ConnectionInterface $db) { $this->db = $db; } public function findByKeyword($keyword) { // this might have a query builder, keyword processing, etc. - this is // a totally naive example just to illustrate the DB dependency, mkay? return $this->db->fetch("SELECT * …
8
在不进行广泛模拟的情况下，应该如何编写单元测试？
据我了解，单元测试的重点是隔离测试代码单元。这意味着： 它们不应被代码库中其他地方不相关的代码更改破坏。 与集成测试相反（集成测试可能会中断），只有一个单元测试应该通过被测试单元中的错误来破坏。 所有这些暗示着，应该模拟掉测试单元的所有外部依赖关系。我的意思是所有外部依赖关系，而不仅仅是网络，文件系统，数据库等“外部层”。 这得出一个合理的结论，几乎每个单元测试都需要模拟。另一方面，谷歌对嘲笑的快速搜索显示了成千上万的文章声称“嘲笑是一种代码味道”，应该（尽管不完全）避免。 现在，到问题。 单元测试应如何正确编写？ 它们和集成测试之间的界线到底在哪里？ 更新1 请考虑以下伪代码： class Person { constructor(calculator) {} calculate(a, b) { const sum = this.calculator.add(a, b); // do some other stuff with the `sum` } } 可以在Person.calculate不模拟Calculator依赖关系的情况下测试该方法的测试（假定，它Calculator是不访问“外部世界”的轻量级类）可以视为单元测试吗？
7
使用验收和集成测试代替单元测试是否足够？
这个问题的简短介绍。我现在已经使用TDD，最近使用BDD已经超过一年了。我使用诸如嘲笑之类的技术来更有效地编写测试。最近，我开始了一个个人项目，为自己编写一个小小的资金管理程序。由于我没有遗留代码，因此从TDD开始是一个完美的项目。不幸的是，我没有体验到TDD的喜悦。它甚至破坏了我的乐趣，以至于我放弃了这个项目。 怎么了 好吧，我使用了类似TDD的方法来使测试/需求发展程序的设计。问题在于，超过一半的开发时间用于编写/重构测试。所以最后我不想实现任何其他功能，因为我需要重构并编写许多测试。 在工作中，我有很多遗留代码。在这里，我写了越来越多的集成和验收测试，以及更少的单元测试。这似乎不是一个坏方法，因为大多数错误是通过验收和集成测试检测到的。 我的想法是，最终我可以编写比单元测试更多的集成和验收测试。就像我说的那样，对于检测错误，单元测试并不比集成/验收测试好。单元测试也对设计有益。由于我曾经写过很多文章，所以我的类总是被设计为可测试的。此外，在大多数情况下，让测试/需求指导设计的方法可导致更好的设计。单元测试的最后一个优点是它们更快。我已经写了足够多的集成测试，知道它们可以和单元测试一样快。 在浏览网络后，我发现这里和那里提到的想法非常相似。您如何看待这个想法？ 编辑 在一个例子中回答这个设计很好的例子，但是我需要对下一个需求进行大量重构： 首先，执行某些命令有一些要求。我编写了一个可扩展的命令解析器-从某种命令提示符下解析命令，并在模型上调用正确的命令。结果以视图模型类表示： 这里没有错。所有类都彼此独立，我可以轻松添加新命令，显示新数据。 下一个要求是，每个命令应具有其自己的视图表示形式-命令结果的某种预览。我重新设计了程序，以针对新要求实现更好的设计： 这也很好，因为现在每个命令都有自己的视图模型，因此也有自己的预览。 事实是，命令解析器已更改为使用基于令牌的命令解析，并且剥夺了其执行命令的能力。每个命令都有自己的视图模型，数据视图模型只知道当前的命令视图模型，而不知道必须显示的数据。 我现在想知道的是，新设计是否没有违反任何现有要求。我不必更改任何我的验收测试。我不得不重构或删除几乎每个单元测试，这是一大堆工作。 我想在这里展示的是在开发过程中经常发生的一种常见情况。旧的或新的设计都没有问题，它们只是随需求而自然变化-我的理解是，TDD的优点之一就是设计不断发展。 结论 感谢您的所有答案和讨论。在此讨论的总结中，我想到了一种方法，将在下一个项目中对其进行测试。 首先，我在像往常一样执行任何操作之前编写所有测试。 对于需求，我首先编写一些验收测试，以测试整个程序。然后，我为需要实现需求的组件编写了一些集成测试。如果有一个组件与另一个组件紧密协作以实现此要求，那么我还将编写一些集成测试，其中两个组件都需要一起测试。最后但并非最不重要的一点是，如果我必须编写一个具有高排列的算法或任何其他类（例如，序列化程序），我将为此特定类编写单元测试。所有其他类均未经测试，但未经任何单元测试。 对于错误，可以简化过程。通常，错误是由一个或两个组件引起的。在这种情况下，我将为测试该错误的组件编写一个集成测试。如果它与算法有关，我只会编写一个单元测试。如果不容易检测到发生错误的组件，我将编写验收测试以查找错误-这应该是一个例外。
5
是否有对所有公开进行存根和模拟的单元测试的意义？
当以“适当”的方式进行单元测试时，即对每个公用电话进行存根并返回预设值或模拟，我觉得我实际上并没有进行任何测试。我从字面上看我的代码，并基于通过公共方法的逻辑流创建示例。每次实现更改时，我都必须再次更改那些测试，而不是真的感觉自己正在完成任何有用的事情（无论是中期还是长期的）。我也进行集成测试（包括不愉快的路径），我并不介意增加测试时间。有了这些，我觉得我实际上是在测试回归，因为它们已经捕获了多个，而单元测试所做的只是告诉我，我已经知道，公共方法的实现已更改。 单元测试是一个广泛的话题，我觉得我是一个不了解这里内容的人。与集成测试（不包括时间开销）相比，单元测试的决定性优势是什么？
5
如果我已经有集成测试，是否需要单元测试？
如果我已经对我的程序进行了集成测试，并且都通过了测试，那么我有很好的感觉，它可以工作。那么编写/添加单元测试的原因是什么？由于无论如何我都必须编写集成测试，所以我只想为集成测试未涵盖的部分编写单元测试。 我知道单元测试优于集成测试的好处是 体积小，因此运行速度快（但是，通过集成测试已经测试了添加新单元以测试某件东西，这意味着我的总体测试服变得越来越大，并且运行时间更长） 由于只测试一件事，因此更容易找到错误（但是，当我的集成测试失败时，我可以开始编写单元测试来验证每个单独的部分） 查找集成测试中可能未捕获的错误。例如掩盖/抵消错误。（但是，如果我的集成测试通过了所有测试，这意味着即使存在一些隐藏的错误，我的程序也可以运行。因此，找到/修复这些错误并不是真正的高优先级，除非它们开始破坏未来的集成测试或引起性能问题） 而且，我们总是希望编写更少的代码，但是编写单元测试需要更多的代码（主要是安装模拟对象）。我的一些单元测试和集成测试之间的区别在于，在单元测试中，我使用模拟对象，而在集成测试中，我使用真实对象。其中有很多重复项，即使在测试中，我也不喜欢重复的代码，因为这会增加更改代码行为的开销（重构工具无法始终保持所有工作）。
3
集成测试如何批评设计？
我正在JB Rainsberger的博客中阅读有关集成测试的文章，并想知道集成测试对我们的设计而言哪种方式更为苛刻？ 我们编写了更多的集成测试，这些测试更大，并且不会像微型测试那样苛刻地批评我们的设计。
3
集成测试是否要重复所有单元测试？
假设我有一个函数（用Ruby编写，但每个人都应该理解）： def am_I_old_enough?(name = 'filip') person = Person::API.new(name) if person.male? return person.age > 21 else return person.age > 18 end end 在单元测试中，我将创建四个测试以涵盖所有场景。每个Person::API对象都将使用带有stubbed方法male?和的模拟对象age。 现在谈到编写集成测试。我认为不应再嘲笑Person :: API。因此，我将创建完全相同的四个测试用例，但不模拟Person :: API对象。那是对的吗？ 如果是，那么编写单元测试的意义何在？如果我可以编写使我更有信心的集成测试（因为我在处理真实对象，而不是存根或模拟对象）？
9
不编写单元测试是合理的，因为它们往往会在以后被注释掉，或者因为集成测试更有价值？
我正在与一位同事讨论单元/集成测试，他提出了一个有趣的案例来反对编写单元测试。我是大型单元测试（主要是JUnit）的支持者，但是我很想听听其他人的看法，因为他提出了一些有趣的观点。 总结他的观点： 当发生重大代码更改时（新的POJO集，主要应用程序重构等），单元测试往往被注释掉而不是重新编写。 最好将时间花在涉及用例的集成测试上，这会使范围较小的测试变得不那么重要。 有这个想法吗？尽管集成测试听起来至少有价值，但我仍在进行单元测试（因为我一直认为它会产生改进的代码）。
7
我什么时候应该编写集成测试？
根据TDD的规则，单元测试是在生产代码之前编写的，但是，在具体（非模拟）有线对象之间进行交互的集成测试又如何呢？ 它们应该在单元测试之前还是在生产代码之后编写，仅用于测试“接线”？ 请注意，我不是在谈论验收或功能测试，而是在进行较低级别的集成测试。
6
数据库和单元/集成测试
我曾与某人讨论过Web应用程序的单元/集成测试，但我对1个核心思想存在分歧。问题是我正在谈论的人认为，单元测试工作所在的数据库应该在其中预先填充数据，并且我认为在执行测试之前和之后它应该完全为空。 我对数据库中预先填充的数据的担心是，无法确保数据保持良好状态。测试本身将要在数据库中创建，删除和修改数据，因此我真的看不到在开始测试之前在数据库中存储数据是一件好事。 似乎最好的测试数据库功能的方法是进行以下设置： 在测试实际运行之前的“设置”阶段，您首先要截断数据库中的所有表 然后，插入将要运行的测试用例所需的所有数据 然后运行并验证测试用例 然后在“拆卸”阶段，您再次截断数据库中的所有表 我没有其他更好的方法来确保要测试的数据是可以测试的好数据。 我在这里想念什么吗？这不是测试数据库相关功能的最佳方法吗？始终存在于数据库中的预填充数据库是否有好处（即使在开始测试之前或在测试完成之后）？对想法进行不同解释以更好地阐明我的观点的任何帮助也将是很棒的（也就是说，如果我的观点是有价值的）。
2
集成测试是否使用模拟？
我目前在软件测试课程中，对于我们的学期项目，我们必须对其执行多种类型的测试，例如单元测试和集成测试。教授说，对于集成测试，在我们的集成测试中使用了模拟和模拟库（例如EasyMock和Mockito）。不过我有点困惑。集成测试是在类，模块，服务等外部进行测试。如果要测试多个类和服务，为什么在集成测试中应适当使用模拟和存根？
4
CI如何用于解释语言？
我以前从未使用过持续集成系统（CI）。我主要使用MATLAB，Python或PHP进行编码。这些都没有构建步骤，我看不到如何将CI用于我的工作。一家大型公司的大型项目中的一位朋友告诉我，语言并不重要。 如果没有构建步骤，我看不到CI对我有什么用。我可以将CI视为可以运行单元测试的测试环境。我想念什么吗？
8
如何处理大量失败的测试？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我正在开发一个用Java编写的旧项目。我们有超过1000万个LOC，更糟糕的是，有4000多个功能测试。 由哈德森（Hudson）安排的测试由于每次较大的代码更改而疯狂，但都失败了。验证测试失败-如果是产品或测试中的问题，则需要几个月的时间。我们无法删除旧测试，因为我们不知道它们在测试什么！ 我们能做什么？如何进行如此大量的传统测试？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.