Questions tagged «unit-testing»

我为类分配编写了一些排序算法，并且还编写了一些测试以确保算法正确实现。我的测试只有10行，其中有3行，但是3行之间只有1行更改，因此有很多重复的代码。将此代码重构为另一个可以在每次测试中调用的方法是否更好？然后，我不需要编写另一个测试来测试重构吗？有些变量甚至可以上移到类级别。测试类和方法是否应该遵循与常规类/方法相同的规则？ 这是一个例子： [TestMethod] public void MergeSortAssertArrayIsSorted() { int[] a = new int[1000]; Random rand = new Random(DateTime.Now.Millisecond); for(int i = 0; i < a.Length; i++) { a[i] = rand.Next(Int16.MaxValue); } int[] b = new int[1000]; a.CopyTo(b, 0); List<int> temp = b.ToList(); temp.Sort(); b = temp.ToArray(); MergeSort merge = new MergeSort(); …

11 testing  unit-testing  code-quality 

我今天早上在看一些博客文章，偶然发现了这一篇： 如果唯一实现Customer接口的类是CustomerImpl，那么您实际上就没有多态性和可替代性，因为实际上在运行时没有什么可以替代。这是假的普遍性。 这对我来说很有意义，因为实现接口会增加复杂性，而且，如果只有一种实现，则可能会争辩说它会增加不必要的复杂性。编写比需要的抽象要抽象得多的代码通常被认为是被称为“投机性一般性”的代码气味（在文章中也提到了）。 但是，如果我遵循TDD，那么如果没有这种推测性的普遍性（无论是接口实现形式还是我们的其他多态选项），就无法（轻松）创建测试双打，从而使类可继承且其方法是虚拟的。 那么，我们如何协调这种权衡呢？以投机性方式推广测试/ TDD是否值得？如果您使用的是测试双打，是否将这些视为第二种实现方式，从而使普遍性不再具有推测性？您是否应该考虑一个更重的模拟框架，该框架可以模拟具体的协作者（例如，C＃世界中的Moles与Moq）？或者，您应该使用具体的类进行测试，并编写什么可以被视为“集成”测试，直到您的设计自然需要多态性之前？ 我很想阅读其他人对此事的看法-预先感谢您的意见。

11 design  unit-testing  code-smell  polymorphism 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 我一直对重写工作代码持怀疑态度-移植代码也不例外。但是，随着TDD和自动化测试的到来，重写和重构代码更加合理。 有谁知道是否存在可用于移植旧代码的TDD工具？理想情况下，您可以执行以下操作： 为通过的旧代码编写语言不可知的单元测试（如果发现错误，则失败）。 在失败的其他代码库上运行单元测试。 用通过测试的新语言编写代码，而无需查看旧代码。 另一种选择是将步骤1分为“用语言1编写单元测试”和“将单元2移植到语言2”，这将显着增加所需的工作量，并且很难证明是否要在维护旧代码库之后停止维护端口（也就是说，您无法在此代码库上获得持续集成的好处）。 编辑：值得注意在StackOverflow上的此问题。

11 unit-testing  language-agnostic  porting 

我最近遇到了“ 圈复杂度”问题，我想尝试更好地理解它。 计算复杂度的不同因素有哪些实用的编码示例？具体来说，对于的Wikipedia等式M = E − N + 2P，我想更好地理解以下各个术语的含义： E =图的边数 N =图的节点数 P =连接的组件数 我怀疑E或N可能是代码块中决策点的数量（如果是，则是foreach等），但是我不确定是哪个代表另一个。我还猜测P是指函数调用和类实例化，但是鉴于我可以看到，没有一个明确的定义。如果某人可以通过一些清晰的代码示例来阐明更多信息，那将会有所帮助。 作为后续措施，环复杂性是否与100％路径覆盖所需的单元测试数量直接相关？例如，复杂度为4的方法是否表示需要4个单元测试才能覆盖该方法？ 最后，正则表达式会影响环复杂度吗？

11 unit-testing  cyclomatic-complexity 

有哪些策略可用于自动创建单元测试用例？为了能够至少生成一个不错的测试用例框架，您需要在每个类中研究哪些方面？ 我意识到综合的自动解决方案不切实际，但是我想至少通过创建一个骨架来加快测试的创建速度。我不是在寻找代码示例，而只是在寻找一些从何处开始的建议或在何处进行过类似的示例，这样我就可以了解他们如何实现它以及可能的实现方式。 我对在PHP中创建单元测试框架的方法特别感兴趣，该方法没有提供其他语言提供的所有工具，例如完整的类型提示。

11 php  unit-testing 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 我一直在寻找有关单元测试的好的演示文稿（首选幻灯片+音频或视频），但我似乎只找到书籍和博客文章。演示文稿不应超过50分钟，因为它将在一个棕色袋子的午餐中显示。我正在寻找一般概念或如何在.NET平台上进行操作。 您可以推荐适合该描述的演示文稿吗？

11 .net  unit-testing  presentation 

即使我没有参加过TDD或BDD项目，或者我曾经在其中说他们正在进行TDD，但距离该项目还很遥远，但这些都是我在考虑的事情，实际上我会尽力阅读关于。 回到问题。在执行BDD时，您应该先编写“测试”并使其失败，对吗？然后实现该功能或您所说的功能。但是，如果您将其推向极致，那难道不是某种自上而下的开发吗？您正在查看自己的UI，并说：“我想在此使用此功能/行为”。然后，您可以修复UI以实现该功能以及支持该UI的代码。至此，您尚未实现任何业务逻辑或数据访问逻辑，而只是实现了行为。我要针对的目标不是先编写测试，而是先编写UI代码。在某些情况下，这将导致数据访问和业务层使用相同的代码，因为您使用UI代码来定义业务需要支持的内容。 当然，您应该为此进行补充测试，以确保该功能正常运行。 有什么想法吗？

11 unit-testing  tdd 

我最近注意到的是，当我执行以下类型的项目时： 开始项目时 处理MVP /原型 添加未完全定义的功能 从事较小规模的项目 作为参考，我正在研究一个Python项目，该项目目前有大约1k行代码，包括一些注释和所有空格。 我发现首先编写集成测试，处理代码，然后对API进行某种程度的加固后，实际上可以轻松地添加单元测试。可以说，我可以在我的main函数上运行的测试类型比其他任何东西都更“端到端”。 这是因为当API发生相当快速的更改时，单元测试确实很烦人，而在与以上任何或大多数条件匹配的项目上工作时，通常就是这种情况。 这种方法是否是一种好的方法，并且在针对这些类型的项目做出是否首先从单元测试或集成测试开始的决策时应考虑哪些标准？在API更加巩固之前，我是否错过了对这类项目进行单元测试的价值？

11 design  unit-testing  integration-tests 

如果我们通过测试调用该函数B的函数C来测试函数B，即编写测试程序以测试调用该函数B的函数C，那么该测试方法是否仍称为单元测试，还是其他？ 什么时候最好在调用目标函数的函数上进行间接测试，什么时候最好直接对一个函数进行测试？

11 unit-testing  testing 

我已经进行了一年的TDD测试，对此我感觉很好，我喜欢我的测试套件以及所有其他工具。但是，我注意到最近我一直在做很多模拟通话验证。例如，我有一个将注入存储库的服务-在我的单元测试中，我将传递一个存储库的模拟并验证它在我正在测试的方法中被调用。然后，我将检查返回的结果是否正确（在另一个测试中）。这绝对是“感觉”错误，因为我的单元测试现在与实现细节非常相关。我听说您应该测试“行为”，但是在许多情况下……嗯-不可能吗？如果你有一个void例如，您通常会测试副作用。我的意思是继续进行并展示一些简单的代码集很容易就能证明这一点，但是恕我直言，它不能很好地反映我们编写的真实程序。我做错了吗？这种测试是一种反模式吗？感谢您对此的意见，在TDD方面，我还是一个新手。

11 unit-testing  tdd  code-smell  anti-patterns 

在我看来，单元测试用例本身就是代码的文档。我的公司希望我在单元测试用例的顶部编写详细的Java文档注释。是否有必要这样做？你这样写评论吗？

11 unit-testing  documentation 

目前，我们正在项目中编写单元测试用例。数据库方法的实现存在并且运行良好。在这种情况下，为什么我们需要编写模拟对象？有什么具体原因吗？为什么我不能直接测试DAO限制？

11 unit-testing 

我最近完成了针对硕士课程的软件工程课程的期末考试，该考试中的一个问题如下： Unit Testing is considered: a. White-box Testing b. Black-box Testing c. Either 在我7年的软件开发经验中，单元测试始终采用白盒方法。测试人员在编写测试时始终对单元的实施有充分的了解。黑盒测试总是以集成，系统和验收测试的形式出现。 但是，对考试的正确答案（根据教授的说法）是单元测试可以是白盒测试或黑盒测试。 我已经进行了一些研究，似乎很多情况下都使用“黑盒单元测试”来描述一种先测试的方法，即在代码之前编写单元测试。但是我认为这仍是白盒测试。尽管实现尚不存在，但是编写测试的人通常都对如何实现源代码有一个很好的了解。 有人可以告诉我黑匣子单元测试的工作原理（如果确实如此），以及它与白匣子单元测试有何不同？

11 unit-testing  testing  tdd 

与测试的持续集成对于确保始终检查“可运输”代码很有用。 但是，要保持一套全面的测试确实很困难，而且常常感觉该版本无论如何都会出错。 您必须对CI管道测试充满信心的进行多少次测试？您是否使用某种指标来确定何时有足够的测试？

10 unit-testing  testing  continuous-integration 

在工作中，我们有一个非常复杂的系统。我们将此系统称为System_A。我们的质量检查小组创建了另一个系统，称为系统_B，以测试系统_A。 System_B的使用方式如下。我们生成输入（使用System_B本身）IN，再通过System_B处理此类输入，并生成输出O_B。因此过程如下： System_B(IN) -> O_B。 然后，我们对System_A进行相同的操作以生成自己的输出O_A： System_A(IN) -> O_A。 在任何时候，都假定O_B是预期输出，而O_A是观测/实际输出。暗示O_B是“金”源（事实）。但是，我们遇到了一系列问题。 O_A是错误的，O_B是正确的 O_A是正确的，O_B是正确的 O_A错误，O_B错误 O_A是正确的，O_B是错误的 如果假定O_B永远是对的（或期望的是什么），谁来决定对的呢？好吧，事实证明，在人工检查和分析中，O_B有时（或经常）是错误的。使用此过程，一切都会通过质量检查，真正的用户会抱怨，我们回到发现O_B毕竟是错误的。 问题是这样的：创建“测试系统”以测试实际系统是否是错误的做法？ 湿滑的斜坡呢？然后，我们不能说我们需要另一个系统来测试“测试系统”吗？ 成本绝对是高得让人望而却步，因为开发人员现在需要学习至少2个代码库，而System_B的复杂性可能大于System_A。我们如何量化拥有System_B对组织有多好？ 创建System_B的最初“诱人”原因之一是“自动化”测试。现在，我们为完全自动化而感到自豪（因为System_B生成输入以引导使用其自身也生成输出的过程）。但是我认为我们以一种无法量化的方式造成了更大的伤害并引入了更多的复杂性。质量检查的工作是否完全自动化？这个理由足以证明创建并行系统吗？ 我真正担心的是，即使我们都知道System_B是错误的（经常）。如果System_B擅长处理输入并且其输出是黄金来源，为什么不用System_B替换System_A？为此，没有人能够提供满意的答复。 对此问题的任何指导表示赞赏。

10 unit-testing  testing  qa  acceptance-testing  integration-testing