Questions tagged «unit-testing»

初步说明 我不会区分不同种类的测试，在这些站点上已经有一些与此有关的问题。 我会采取什么样的存在，并且说：单位的“测试应用程序的最小单位可分离”的意义测试从这个问题实际上导出 隔离问题 程序的最小可隔离单元是什么。好吧，正如我所见，它（高度？）取决于您所使用的语言。 Micheal Feathers谈到接缝的概念：[WEwLC，p31] 接缝是一个您可以更改程序行为而无需在该位置进行编辑的位置。 而且，在不进行细节讨论的情况下，我了解到在单元测试的上下文中存在的缝隙—在程序中可以使“测试”与“单元”进行交互。 例子 单元测试-尤其是C ++中的单元测试-要求被测试的代码添加更多的接缝，这对于给定的问题是严格要求的。 例： 在非虚拟实现就足够的地方添加虚拟接口 拆分-generalizing（？）-一个（较小的）类，进一步“恰好”以方便添加测试。 将单个可执行项目拆分为看似“独立”的库，“公正”以便于为测试而独立地编译它们。 问题 我将尝试一些可能会问相同问题的版本： 单元测试是“仅”对应用程序代码进行结构化的一种方式，这对单元测试是有益的，还是实际上对应用程序结构有利。 是需要的代码泛化作出任何它的单位可测试非常有用，但单元测试？ 添加单元测试是否会强制一个泛化？ 从问题域的角度来看，形状单元测试对代码的“总是”作用力是否也对代码总体而言是一种良好的形状？ 我记得有一条经验法则，直到您需要/直到有第二个地方使用该代码时，它才会泛化。使用单元测试，总是有第二个地方使用代码-即单元测试。那么，这个理由足以概括吗？

20 c++  unit-testing  tdd  generalization 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 6年前关闭。 下周，我将与我的部门进行有关单元测试和测试驱动开发的演讲。作为其中的一部分，我将展示一些我最近编写的代码中的真实示例，但我也想展示一些我将在演讲中编写的非常简单的示例。 我一直在网上寻找良好的例子，但一直在努力寻找任何特别适合我们开发领域的例子。我们编写的几乎所有软件都是在小型微控制器上运行的深层控制系统。只要您远离“底层”层，就有很多C代码很容易适用于单元测试（我将在PC上而不是在目标本身上谈论单元测试）：直接对话的东西到微控制器外设。但是，我发现的大多数示例都倾向于基于字符串处理（例如出色的Dive Into Python罗马数字示例），并且由于我们几乎从未使用过字符串，因此这实际上并不适合（关于我们的代码通常使用的唯一库函数）是memcpy，memcmp和memset，strcat 或正则表达式不太正确）。 那么，问题就来了：请问有人可以提供一些很好的功能示例，这些功能可以用来在实时会话中演示单元测试吗？在我的观点（可能会发生变化）中，一个好的答案可能是： 一个足够简单的功能，任何人（甚至只是偶尔写代码的人）都可以理解； 看起来没有意义的函数（即计算奇偶校验或CRC可能比将两个数字相乘并添加随机常数的函数更好）； 一个足够短的函数，可以在一个人的房间里书写（我可能会利用Vim的许多剪贴板来减少错误……）； 该函数以数字，数组，指针或结构为参数，并返回相似的内容，而不是处理字符串。 具有简单错误（例如>而不是>=）的函数易于插入，在大多数情况下仍然可以使用，但在某些特殊情况下会中断：易于通过单元测试进行识别和修复。 有什么想法吗？ 尽管可能无关紧要，但是测试本身可能会使用Google Test Framework以C ++编写：我们所有的标头都已经包含了#ifdef __cplusplus extern "C" {包装器；到目前为止，这与我已经完成的测试效果很好。

20 unit-testing  c  tdd  embedded-systems 

在研究单元测试最佳实践以帮助为我的组织制定准则时，我遇到了一个问题，即分离测试装置（测试类）还是将一个类的所有测试保存在一个文件中是更好还是有用。 首先，我纯粹是指“单元测试”，它们是针对单个类，每个测试一个断言，所有依赖项都被嘲笑的白盒测试。 一个示例场景是一个类（称为Document），它具有两个方法：CheckIn和CheckOut。每种方法实现控制其行为的各种规则等。按照每次测试一个断言的规则，每种方法我将有多个测试。我可以将所有测试放在一个单独的DocumentTests类中，其名称类似于CheckInShouldThrowExceptionWhenUserIsUnauthorized和CheckOutShouldThrowExceptionWhenUserIsUnauthorized。 或者，我可以有两个单独的测试类：CheckInShould和CheckOutShould。在这种情况下，我的测试名称将被缩短，但是它们会被组织起来，以便针对特定行为（方法）的所有测试都在一起。 我确定这两种方法都有优缺点，并且想知道是否有人使用多个文件进行了路由，如果是，为什么？或者，如果您选择了单文件方法，为什么感觉更好呢？

20 testing  tdd  unit-testing 

我想知道自Java 8出现以来，当前使用Java的工具来衡量条件代码覆盖率是否还没有过时。使用Java 8 Optional，Stream我们通常可以避免代码分支/循环，这使得在不测试所有可能的执行路径的情况下轻松获得很高的条件覆盖率。让我们将旧的Java代码与Java 8代码进行比较： 在Java 8之前： public String getName(User user) { if (user != null) { if (user.getName() != null) { return user.getName(); } } return "unknown"; } 以上方法有3条可能的执行路径。为了获得100％的条件覆盖率，我们需要创建3个单元测试。 Java 8： public String getName(User user) { return Optional.ofNullable(user) .map(User::getName) .orElse("unknown"); } 在这种情况下，分支是隐藏的，我们只需要进行一次测试即可获得100％的覆盖率，无论哪种情况我们都将进行测试。我相信，尽管仍然存在相同的三个逻辑分支。我认为这使有条件覆盖范围统计这些天完全不可信。 测量Java 8代码的条件覆盖范围是否有意义？还有其他工具可以发现未经测试的代码吗？

19 java  unit-testing  test-coverage  java8 

我正在编写一个解析器，作为其中的一部分，我有一个Expander将单个复杂语句“扩展”为多个简单语句的类。例如，它将扩展此内容： x = 2 + 3 * a 变成： tmp1 = 3 * a x = 2 + tmp1 现在，我正在考虑如何测试此类，特别是如何安排测试。我可以手动创建输入语法树： var input = new AssignStatement( new Variable("x"), new BinaryExpression( new Constant(2), BinaryOperator.Plus, new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a")))); 或者我可以将其编写为字符串并进行解析： var input = new Parser().ParseStatement("x = 2 + 3 * a"); …

19 unit-testing  testing  integration-tests 

我正在一个具有几种文件格式的项目。某些格式由.xsds指定，其他格式由各自网站上的文档指定，而某些格式是自定义的内部格式，没有文档。姆哈哈哈哈哈 有什么问题？ 我想测试我的文件阅读器，但是我不确定如何去做。应用程序的流程是这样的： file.___ ===> read by FileReader.java ===> which creates a Model object FileReader接口在哪里 public interface FileReader { public Model read(String filename); } 在Model拥有一批在读文件已填充属性。看起来像 public class Model { List<String> as; List<String> bs; boolean isAPain = true; // ... } 我尝试了什么？ 我唯一的想法是为每种文件格式创建文件“生成器”。这些生成器基本上是生成器，它们接受一些变量（例如，要在文件中生成的注释数量），并输出一个样本文件，然后我将其读入并将结果Model与我最初用于生成文件的变量进行比较。 但是，这有一些问题： 它生成的文件看起来不像真实文件。生成器绝不了解上下文。 由于我是手动设置变量的生成器，因此很难识别生成器是否针对边缘情况生成了。这种方法仅比我创建十几个示例文件更好。 有没有更好的方法可以做到这一点？ 编辑：将单元更改为集成，因为这实际上是我的意思。 EDIT2：这是我提到的边缘案例的示例。 每个文件代表一个由顶点和边组成的图形。这些顶点和边可以以不同的方式连接，因此： v1 …

19 unit-testing  language-agnostic  integration-tests  file-handling 

我需要在这个问题上扮演一个恶魔倡导者，因为由于缺乏经验我无法很好地捍卫它。这是交易，我从概念上得到了单元测试和集成测试之间的区别。当专门关注持久性方法和存储库时，单元测试可能会通过Moq之类的框架使用模拟，以断言所搜索的订单已按预期返回。 假设我已经建立了以下单元测试： [TestMethod] public void GetOrderByIDTest() { //Uses Moq for dependency for getting order to make sure //ID I set up in 'Arrange' is same one returned to test in 'Assertion' } 因此，如果我设置好OrderIdExpected = 5并且我的模拟对象返回5了ID，那么我的测试就会通过。我知道了。我对代码进行了单元测试，以确保我的代码瓶坯返回期望的对象和ID，而不返回其他内容。 我将得到的参数是这样的： “为什么不跳过单元测试并进行集成测试呢？这是一起测试数据库存储过程和代码的重要性。当最终我想知道数据库是否调用时，进行单元测试和集成测试似乎是多余的工作。我知道测试需要花费更长的时间，但是无论如何都必须运行和测试它们，所以对我来说，两者都显得毫无意义。只需对重要问题进行测试。” 我可以用诸如以下的教科书定义来捍卫它：“嗯，这是一个集成测试，我们需要将代码作为单元测试和yada，yada，yada分别进行测试。”这种情况是一种纯粹的实践解释与现实的对比正在消失。有时我会碰到这种情况，如果我无法捍卫最终依赖于外部依赖关系的单元测试代码背后的原因，那我就没有理由了。 非常感谢您对这个问题的任何帮助，谢谢！

19 unit-testing  integration-tests 

我公司的软件开发负责人只是“辞职”（即被解雇），我们现在正在研究改善公司的开发实践。我们希望在以后创建的所有软件中实施单元测试。 开发人员的反馈是： 我们知道测试很有价值 但是，您总是在更改规格，因此会浪费时间 而且，您的截止日期太紧了，我们还是没有足够的时间进行测试 CEO的反馈是： 我希望我们的公司进行自动化测试，但我不知道如何实现 我们没有时间编写大型规范文档 开发人员现在如何获得规格？口耳相传或PowerPoint幻灯片。显然，这是一个大问题。我的建议是这样的： 我们还为开发人员提供一组测试数据和单元测试 那是规格。管理层需要清楚，定量地了解其需求。 开发人员可以将其认为需要的任何其他功能放入测试中，而无需测试 好吧，如果您曾经在一家处于这种情况的公司任职，那么您是如何解决问题的？这种方法看起来合理吗？

19 unit-testing  tdd 

我编写了一个类，用于管理MailChimp列表上的收件人，称为MailChimpRecipient。它使用MCAPI类，它是第三方API包装器。 http://apidocs.mailchimp.com/api/1.3/ http://apidocs.mailchimp.com/api/downloads/ 我将MCAPI对象传递给MailChimpRecipient对象的构造函数，因此我已经使用PHPUnit编写了单元测试，该单元测试可以测试我自己的类中的所有逻辑（我不测试MCAPI类）。我有100％的代码覆盖率，所有测试均通过。这是通过模拟和存根MCAPI对象来完成的。 我的下一步是使用PHPUnit编写集成测试，在该测试中，我将使用真实的MCAPI对象构造MailChimpRecipient固定装置，并设置为使用真实的MailChimp列表。 我写了我认为是集成测试的内容，它基本上是在对象的公共接口上再次运行测试，例如： public function testAddedRecipientCanBeFound() { $emailAddress = 'fred@fredsdomain.com'; $forename = 'Fred'; $surname = 'Smith'; // First, delete the email address if it is already on the list $oldRecipient = $this->createRecipient(); if($oldRecipient->find($emailAddress)) { $oldRecipient->delete(); } unset($oldRecipient); // Add the recipient using the test data $newRecipient = …

19 php  unit-testing 

我刚刚负责一个涉及可维护性问题的代码项目。我怎样做才能使项目稳定下来？ 我发现自己在一个我们正在使用非常大型的多层.NET系统的地方，该系统缺少许多重要的东西，例如单元测试，IOC，MEF，太多的静态类，纯数据集等。只有24岁，但我已经在这里待了将近三年（此应用程序已经开发了5年），并且主要是由于时间限制，我们一直在添加更多的废话以适应其他废话。在空闲时间做完许多项目之后，我开始理解所有这些概念的重要性。同样由于员工的转移，我发现自己现在是这个项目的团队负责人，我真的很想提出一些聪明的方法来改进此应用程序。可以向管理层解释价值的方式。我对自己想做的事情有想法，但是这些想法似乎都让人不知所措，没有太多前期收获。关于人们如何或将如何处理这个问题的任何故事都将是非常有趣的读物。谢谢。

19 .net  unit-testing  project-management  patterns-and-practices 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我正在做我的第一个大型项目，在专业编程环境中没有很多经验。在研究与编程相关的任何东西时，我经常会看到有关单元测试的参考，但是对于如何设置这些参数甚至对我来说还是有益的，我仍然不清楚。 有人可以向我解释单元测试，以及如何在具有多个项目的Visual Studio 2010解决方案中进行设置吗？是项目解决方案中发生的事情，还是单独的解决方案？您会为小型开发团队推荐它吗，还是只是在浪费时间设置？ 现在，我只是运行整个程序以测试当前正在处理的内容，但是偶尔我会遇到不容易调试的问题，在其他地方运行代码的子集很有用...有时我会设置另一个项目中引用了一些库来测试程序的一小部分，但由于涉及到所有相关性，我觉得浪费了更多的时间进行设置，然后仅运行整个程序

19 unit-testing  visual-studio-2010 

目前，我的工作是为C ++应用程序提供大量的单元测试。但是，我们不使用单元测试框架。他们只是利用了一个C宏，它基本上包装了一个断言和一个cout。就像是： VERIFY(cond) if (!(cond)) {std::cout << "unit test failed at " << __FILE__ << "," << __LINE__; asserst(false)} 然后，我们只需为每个测试创建函数，例如 void CheckBehaviorYWhenXHappens() { // a bunch of code to run the test // VERIFY(blah != blah2); // more VERIFY's as needed } 我们的CI服务器会选择“单元测试失败”，并且构建失败，并通过电子邮件将消息发送给开发人员。 如果我们有重复的设置代码，我们可以像在生产中使用的任何其他重复代码一样简单地对其进行重构。我们将其包装在辅助函数的后面，使一些测试类包装设置常用的场景。 我知道那里有CppUnit和boost单元测试之类的框架。我想知道这些增加了什么价值？我想念这些带来的好处吗？我可以从中受益吗？我不愿意添加一个依赖项，除非它增加了实际价值，尤其是因为看起来我们拥有的东西简直太简单了并且运作良好。

19 unit-testing  language-agnostic 

关于测试，我可以想到两个选择： 将测试和应用程序放在一张图中。 在图像中仅包含应用程序代码。创建一个特定于测试的容器，该容器在主映像之后构建并向其添加一些层（测试代码，依赖项等）。 使用第一个选项，我可以测试容器并按照测试的要求完全运送它。明显的缺点是不必要的代码（以及潜在的测试数据）将包含在图像中。 使用第二种选项时，出厂的图像与测试的图像不太相同。 两者看起来都是错误的策略。有没有第三种更好的策略？

19 unit-testing  testing  docker  test-automation 

可以添加这样的延迟断言吗 var actualKittens = actualKittens.Select(kitten => { Assert.IsСute(kitten); return kitten }); 为什么？因此，即使使用期望实现实例化的语句，我也可以仅迭代一次： CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList()); 而且它可能不仅是Select，而且是定义了迭代器且具有大量检查和逻辑（例如，一些计数和过滤）的方法。 令人怀疑的种子是在测试失败的情况下读取和调试此类代码的复杂性。

18 c#  unit-testing  linq  iterator  assertions 

我正在编写（递归）代码来浏览依赖关系图，以查找依赖关系中的循环或矛盾。但是，我不确定如何进行单元测试。问题是我们主要关心的问题之一是将对可能出现的所有有趣的图结构进行代码处理，并确保所有节点都将得到适当处理。 尽管通常100％的行或分支覆盖率足以确保某些代码可以工作，但即使100％的路径覆盖率，您仍然会有疑问。 因此，如何为测试用例选择图形结构，以确保其代码可以处理您在真实数据中发现的所有可能的排列。 PS-如果重要的话，我图中的所有边都标记为“必须具有”或“不能具有”，并且没有琐碎的循环，并且任何两个节点之间只有一条边。 PPS-此附加问题声明最初由问题的作者在以下评论中发布： For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.

18 unit-testing  graph  test-coverage