Questions tagged «integration-tests»

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

1
如何对图像处理代码进行单元测试？
我正在图像处理（主要是OCR）方面工作，我想知道如何在开发中集成单元测试。 我已经在使用单元测试来处理更多“常见”类型的代码，但是在处理图像处理代码时，我不确定该如何处理。这种代码总是需要一些图像数据输入/输出，而对其进行模拟并不明显。目前，我主要进行集成测试，但是它们需要一段时间才能运行，我想了解一些有关如何将这种代码分解为单元测试的想法，以便我可以更快地运行它们。 编辑：分析角色可以经历许多步骤，包括多次旋转，缩放和形态操作。随着算法的发展，这些步骤经常改变。因此，在测试期间，输入和预期输出会发生很大变化。每个字符可以为100x100像素，因此毫无疑问地在代码中对它们进行编码或处理生成的数据。
3
如何使自动化测试流行？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 我们的代码库已经增长了20年。我们大约有10位开发者+平方英尺与500kloc合作。不久前，我们的一个小团队（2个开发人员，一个来自sqa）开始着手进行自动化测试程序。目前，一次运行需要11小时，并且某种程度上是一项集成测试。我们正在努力解决这个问题，减少误报，并在此方面取得了良好的进展。但是细节并不重要。 一切正常，我们将继续对其进行改进。我们（小团队）非常喜欢。如果我们弄坏了东西，我们会在一天后而不是两个月后注意到sqa。此外，我们的经理（开发人员+平方英尺）也很喜欢这个想法。但是团队中的其他人只是忽略了测试结果。在他们看来，如果在签入后测试失败，这是测试的问题，而不是代码更改的问题，这只是我们的玩具项目。如果失败的测试是真正的错误，我们进行了几次讨论。大多数时候是这样。 我们不能也不想强制执行某些事情。我们如何证明自动化测试是一回事？
2
从被测系统中提取类时，应该重构单元测试吗？
我写的这个类做了几件事（也许这违反了单一责任原则）。我现在该项目的其他部分需要意识到一块是逻辑的，我要揭露它是提取的一类了我原来的被测系统的方式。 我期望无需更改任何测试代码即可执行此操作，但是当我完成操作时，您可能会说该测试不再是单元测试。它将测试原始类和我提取的类。换句话说，我将有一个测试用例，但有两个系统正在测试中。 完成后是否应该重构测试代码？IE：创建一个ExtractedClassTest并将所有相关测试从OriginalClassTest移入其中？这似乎有点冒险：我可能会在此过程中失去一些覆盖面，它可能不像移动测试那样简单，并且我最终会重写一些我知道曾经可以使用但无法再使用的测试代码，等等 另一方面，如果按原样保留OriginalClassTest，则可以看到这是测试维护问题。找到ExtractedClass的测试在哪里会有些混乱。您的第一印象将是它不存在。随着时间的推移，随着大量生产代码的重构，这可能会成为一个严重的问题。 我是TDD的新手，所以我需要专家的建议。谢谢！
4
为集成测试选择名称
使用单元测试时，域很小，因此很容易。我使用了Osherove的methodName_conditions_result()方案，发现它很清楚。 但是通过集成测试，我觉得它会叫一个很长的名字，我该用什么代替methodName？如何命名集成测试类？ 集成测试名称的真实示例非常受欢迎。我希望答案也能帮助我更好地理解这些测试。
3
集成测试中应包括集成测试吗？
假设我们正在开发一个Web应用程序，并且Hudson做一些典型的工作，例如编译，单元测试和静态代码分析。 但是棘手的部分是：一旦完成先前的工作，Hudson就会部署并启动应用程序服务器以进行集成测试。 这意味着一些困难的事情，例如数据库连接，第三部分应用程序连接，套接字端口监听，环境变量，服务器启动故障处理等。我们每次都必须正确地设置和拆除这些东西，这很难。更糟糕的是，集成测试会轻易破坏集成测试。 您认为持续集成（CI）中是否应包括集成测试？可以手动吗？还是简化集成测试？
3
我应该在单元测试和集成测试之间划清界限吗？它们应该分开吗？
我有一个正在研究的小型MVC框架。它的代码库肯定不大，但是不再仅仅是几个类。我最终决定尝试一下并开始为此编写测试（是的，我知道我应该一直这样做，但是到目前为止，它的API还是非常不稳定的） 无论如何，我的计划是使其变得非常容易测试，包括集成测试。集成测试示例将遵循以下原则： 伪造的HTTP请求对象-> MVC框架-> HTTP响应对象->检查响应是否正确 因为这一切都可以在没有任何状态或特殊工具（浏览器自动化等）的情况下完成，所以实际上我可以使用常规的单元测试框架轻松地做到这一点（我使用NUnit）。 现在是个大问题。我应该在单元测试和集成测试之间划清界限吗？我是否应该一次（尽可能多地）仅通过单元测试来测试一门课程？另外，是否应该将集成测试与单元测试项目放在同一测试项目中？
2
评估是先在蓝天/原型项目上编写单元测试还是集成测试
我最近注意到的是，当我执行以下类型的项目时： 开始项目时 处理MVP /原型 添加未完全定义的功能 从事较小规模的项目 作为参考，我正在研究一个Python项目，该项目目前有大约1k行代码，包括一些注释和所有空格。 我发现首先编写集成测试，处理代码，然后对API进行某种程度的加固后，实际上可以轻松地添加单元测试。可以说，我可以在我的main函数上运行的测试类型比其他任何东西都更“端到端”。 这是因为当API发生相当快速的更改时，单元测试确实很烦人，而在与以上任何或大多数条件匹配的项目上工作时，通常就是这种情况。 这种方法是否是一种好的方法，并且在针对这些类型的项目做出是否首先从单元测试或集成测试开始的决策时应考虑哪些标准？在API更加巩固之前，我是否错过了对这类项目进行单元测试的价值？
2
单元测试和集成测试的代码覆盖率报告是分开的，还是两者都有一个报告？
应该为单元测试和集成测试提供单独的代码覆盖率报告，还是为两者提供一个代码覆盖率报告？ 其背后的想法是，代码覆盖率使我们能够确保我们的代码已被尽可能多的测试所覆盖（无论如何，现在无论如何机器）。 拥有单独的报告更方便我们了解单元测试未涵盖的内容以及集成测试未涵盖的内容。但是这样一来，我们看不到总覆盖率。
1
OSS项目中的集成测试-如何处理带有身份验证的第三方？
我的一个开源项目是一个备份工具，该工具可从GitHub，Bitbucket等进行脱机存储库备份。 它调用托管者的API来获取存储库列表，然后使用Git / Mercurial /任何克隆/将存储库拉到本地计算机。 因此，我在集成测试中通过身份验证调用了GitHub API。 （并且当克隆/拉动功能完成时，可能会有测试从GitHub克隆存储库，并且还需要进行身份验证） 我创建了一个用户和一个组织，专门用于这些集成测试。 问题：我不能只是在源代码中的某个地方对密码进行硬编码，因为它是开源的，并且代码在GitHub上是公开的。 我现在在做什么 在测试中，我从环境变量中获取所有用户名，密码和存储库名称。 这是一个例子： config.Name = TestHelper.EnvVar("GithubApiTests_Name"); config.Password = TestHelper.EnvVar("GithubApiTests_PW"); （TestHelper.EnvVar是一个帮助程序方法，它获取环境变量的值并在不存在环境变量时引发异常） 然后，我有一个批处理文件，用于设置这些环境变量。 真正的（environment-variables.bat）在构建脚本中以及在执行测试之前被调用，但是在源代码控制中被忽略，因此它实际上不在我的存储库中。 什么是源控制environment-variables.bat.sample，它设定了相同的环境变量，而是用假密码： rem copy/rename this file to environment-variables.bat echo Setting environment variables for integration tests... set GithubApiTests_Name=scm-backup-testuser set GithubApiTests_OrgName=scm-backup-testorg set GithubApiTests_PW=not-the-real-password set GithubApiTests_Repo=scm-backup 因此，我可以将存储库克隆到我的计算机上，将此文件重命名为environment-variables.bat，用真实的密码替换假密码，所有集成测试都将起作用。 这也适用于持续集成-我正在使用AppVeyor，并且可以在Web UI中设置这些环境变量。 我对此不满意 我认为这对于OSS项目不是一个好的解决方案，尤其是对于该项目不是这样： 从理论上讲，我的项目的贡献者现在可以通过以下方式运行集成测试： …
1
测试单元与集成之间的差距：小型，组件，单元集成测试中的集成
在过去的几周中，我一直在研究和研究如何填补我们的测试方法中的空白。简而言之，单元测试太小，而传统的集成测试太大。 经常出现的情况是A，B两者都使用component C。但是A，B对的要求略有不同，并且对做出略有不同的假设C。如果我是A如何以及在哪里测试我的假设的开发人员C？ 显然，A带有模拟假设的单元测试C可以很好地进行A隔离测试，但是它不能测试假设本身。 另一种可能性是为添加单元测试C。但是，这不是理想的，因为A在开发过程中，C根据不断变化的假设更改测试A将非常笨拙。确实，A开发人员甚至可能没有足够的权限访问C（例如，外部库）的单元测试。 用一个更具体的例子来说明这一点：假设这是一个节点应用程序。 A，并B依赖于C读取文件（以及其他内容）并将文件内容存储在传递给的对象中C。最初，所有C处理的文件都很小，可以同步读取而不会产生明显的阻塞。但是，的开发人员B意识到他的文件越来越大，需要切换C到异步读取。这会导致中出现零星的同步错误A，该错误仍假定C是正在同步读取文件。 众所周知，这种错误很难从完整的集成测试中找到，并且根本不会在集成测试中发现。它也不受As单元测试的影响，因为As的假设是模拟的。但是，可以通过“ just” A和“ C。”行使的“迷你”集成测试轻松抓住它。 我只找到了关于这种测试的一些参考。小型集成，组件集成测试，单元集成测试。它还与BDD测试的方向有关，而不是正式的TDD单元测试。 如何填补这个测试空白？具体来说-我应该在哪里进行此类测试？如何嘲笑的投入A，并C为“迷你型”集成测试？在分离这些测试和单元测试之间的测试关注点上应该付出多少努力？还是有更好的方法来填补测试空白？
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.