Questions tagged «tdd»

如果我已经对我的程序进行了集成测试，并且都通过了测试，那么我有很好的感觉，它可以工作。那么编写/添加单元测试的原因是什么？由于无论如何我都必须编写集成测试，所以我只想为集成测试未涵盖的部分编写单元测试。 我知道单元测试优于集成测试的好处是 体积小，因此运行速度快（但是，通过集成测试已经测试了添加新单元以测试某件东西，这意味着我的总体测试服变得越来越大，并且运行时间更长） 由于只测试一件事，因此更容易找到错误（但是，当我的集成测试失败时，我可以开始编写单元测试来验证每个单独的部分） 查找集成测试中可能未捕获的错误。例如掩盖/抵消错误。（但是，如果我的集成测试通过了所有测试，这意味着即使存在一些隐藏的错误，我的程序也可以运行。因此，找到/修复这些错误并不是真正的高优先级，除非它们开始破坏未来的集成测试或引起性能问题） 而且，我们总是希望编写更少的代码，但是编写单元测试需要更多的代码（主要是安装模拟对象）。我的一些单元测试和集成测试之间的区别在于，在单元测试中，我使用模拟对象，而在集成测试中，我使用真实对象。其中有很多重复项，即使在测试中，我也不喜欢重复的代码，因为这会增加更改代码行为的开销（重构工具无法始终保持所有工作）。

47 testing  unit-testing  tdd  integration-tests 

这个问题与单元测试框架无关。 这个问题与编写单元测试无关。 这个问题是关于在哪里放置UT代码以及如何/何时/在哪里编译和运行它。 在有效地使用旧版代码中，迈克尔·费瑟斯断言 良好的单元测试...运行速度快 然后 运行1/10秒的单元测试是缓慢的单元测试。 我认为这些定义确实有意义。我还认为，这意味着您必须分别保留一组单元测试和一组代码测试，这些测试需要更长的时间，但是我想这就是您仅在运行（非常快）时才调用单元测试的价格。 显然，问题在C ++中是“跑”单元测试（小号），你必须： 编辑代码（生产或单元测试，具体取决于您所在的“周期”） 编译 链接 启动单元测试可执行文件（小号） 编辑（经过奇怪的近距离表决）：在进入细节之前，我将尝试在此处总结要点： 如何有效地组织C ++单元测试代码，这样既可以有效地编辑（测试）代码又可以运行测试代码？ 然后，第一个问题是确定将单元测试代码放在哪里，以便： 结合相关的生产代码进行编辑和查看是“自然的”。 轻松/快速地为您当前更改的单元开始编译周期 在第二个的话，相关的，问题是什么来编译，这样的反馈是瞬时的。 极端的选择： 每个单元测试-测试单元都位于一个单独的cpp文件中，并且此cpp文件被单独编译+链接（连同它测试的源代码单元文件）到单个可执行文件，然后该可执行文件运行此一个单元测试。 （+）这样可以最小化单个测试单元的启动（编译+链接！）时间。 （+）测试运行非常快，因为它仅测试一个单元。 （-）执行整个套件将需要启动大量流程。可能是一个管理难题。 （-）流程启动的开销将变得可见 另一面将是-仍然-每个测试一个cpp文件，但是所有测试cpp文件（以及它们测试的代码！）都链接到一个可执行文件中（每个模块/每个项目/选择您的选择）。 （+）编译时间仍然可以，因为只有更改的代码才能编译。 （+）执行整个套件很容易，因为只有一个exe可以运行。 （-）套件将花费很多时间进行链接，因为任何对象的每次重新编译都会触发重新链接。 （-）（？）套装将花费更长的时间运行，尽管如果所有单元测试都很快，则时间应该可以。 那么，现实世界中的C ++ 单元测试如何处理？如果我只是每晚/每小时运行一次，那么第二部分并不重要，但是第一部分，即如何将UT代码“耦合”到生产代码，这样对于开发人员来说，将两者保持一致是“自然的”我认为专注始终很重要。（如果开发人员将UT代码作为重点，他们将要运行它，这将使我们回到第二部分。） 欣赏真实世界的故事和经验！ 笔记： 该问题有意离开了未指定的平台和品牌/项目系统。 问题带有标记的UT＆C ++是一个很好的起点，但是不幸的是，太多的问题（尤其是答案）过于注重细节或特定框架。 前一阵子，我回答了关于升压单元测试的结构的类似问题。我发现这种结构对于“真实的”快速单元测试是缺少的。我发现另一个问题过于狭窄，因此提出了这个新问题。

47 c++  unit-testing  tdd  projects-and-solutions 

如今风靡一时。“每个人”都推荐它。这本身使我感到怀疑。 在进行测试优先（测试驱动）开发时发现了哪些缺点？我正在寻找经验丰富的从业人员的个人经验-我可以在互联网上的其他地方阅读一百个想想的人的假想。 我之所以问并不是因为我不想讨厌TDD，而是因为改善软件开发过程是我的工作，而且我们越了解人们遇到的问题，就越有机会改进该过程。

47 development-process  tdd 

如果您不进行TDD（测试驱动开发），是否可以正确地称呼自己（或您的团队）“敏捷”？

45 agile  tdd 

您如何说服经理让您进行单元测试？ “使用”是指被允许开发，检入源代码控制并随着时间的推移维护单元测试等。 典型的管理异议是： 客户没有为单元测试付费 该项目没有时间进行单元测试 技术债务？什么技术债务？ 您知道其他异议吗？你的答案是什么？ 提前致谢！

45 project-management  management  unit-testing  tdd 

到目前为止，我了解测试驱动的开发，因此仅当单元测试失败（红色）时，才可以编写高效的代码。基于此，我有一个问题，即测试驱动方法是否也可以应用于其他形式的测试。

41 testing  tdd 

在进行红色，绿色和重构循环时，我们应始终编写最少的代码以通过测试。这就是我被教导有关TDD的方式，以及几乎所有书籍都描述该过程的方式。 但是日志记录呢？ 老实说，除非发生真正复杂的事情，否则我很少在应用程序中使用日志记录，但是，我看到无数篇文章都谈到了正确日志记录的重要性。 因此，除了记录异常外，我无法证明在适当的经过测试的应用程序（单元/集成/验收测试）中记录日志的真正重要性。 所以我的问题是： 如果正在执行TDD，是否需要记录？失败的测试不会揭示应用程序有什么问题吗？ 是否应该在每个类的每个方法中为日志记录过程添加测试？ 例如，如果在生产环境中禁用了某些日志级别，这是否会在测试和环境之间引入依赖性？ 人们谈论日志如何简化调试，但是TDD的主要优点之一是，我始终知道由于测试失败而出了什么问题。 有什么我想念的吗？

40 design  object-oriented  unit-testing  tdd  logging 

在项目中，我们已经进行了将近一千次测试，并且人们花了很长时间才停止在进行检入之前运行它们的麻烦。充其量，他们运行与所更改代码段相关的测试，而最糟糕的是，它们仅在未经测试的情况下检入。 我认为这个问题是由于以下事实导致的：解决方案已增长到120个项目（我们通常会做很多较小的项目，这只是我们第二次正确进行TDD），并且构建+测试时间已增长到大约两三分钟在较小的机器上。 我们如何减少测试的运行时间？有技巧吗？假装更多？少假装？也许在运行所有测试时不应该自动运行较大的集成测试？ 编辑：作为对几个答案的回应，我们已经使用CI和构建服务器，这就是我知道测试失败的方式。问题（实际上是一种症状）是我们不断收到有关构建失败的消息。大多数人会执行部分测试，但并非全部。关于测试，它们实际上做得很好，对所有东西都使用伪造品，根本没有IO。

40 c#  unit-testing  tdd  nunit 

我正在JB Rainsberger的博客中阅读有关集成测试的文章，并想知道集成测试对我们的设计而言哪种方式更为苛刻？ 我们编写了更多的集成测试，这些测试更大，并且不会像微型测试那样苛刻地批评我们的设计。

38 tdd  integration-tests 

如果我的代码包含一个应该修复的已知缺陷，但尚未修复，并且不会在当前版本中修复，并且在可预见的将来可能不会修复，如果该缺陷中的某个单元测试失败，测试套件？如果添加单元测试，它将（显然）会失败，并且习惯于失败的测试似乎是个坏主意。另一方面，如果它是一个已知的缺陷，并且存在一个已知的失败案例，那么将其排除在测试套件之外似乎很奇怪，因为应该在某个时间点对其进行修复，并且该测试已经可以使用。

37 unit-testing  tdd 

一段时间以来，我一直在尝试学习为我的代码编写单元测试。 最初，我开始做真正的TDD，在这里我不会写任何代码，除非先编写一个失败的测试。 但是，最近我要解决一个棘手的问题，其中涉及很多代码。在花了几周时间编写测试然后编写代码之后，我得出了一个不幸的结论，即我的整个方法都行不通，我不得不花两周的时间重新开始。 刚编写代码时，这是一个非常糟糕的决定，但是当您还编写了数百个单元测试时，将其全部扔掉在情感上变得更加困难。 我不禁会认为我浪费了3到4天的时间来编写这些测试，因为我本可以将代码放在一起进行概念验证，然后在对方法满意后再编写测试。 练习TDD的人如何正确处理此类情况？在某些情况下是否存在违反规则的情况，或者即使该代码可能看起来毫无用处，您还是总是总是首先刻意编写测试吗？

37 tdd  refactoring 

今天，我们正在培训TDD，发现了以下误解。 该任务是针对输入的“ 1,2”返回数字总和为3的。我用C＃编写的是： numbers = input.Split(','); return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct 但是其他人更喜欢用其他方式。首先，对于输入“ 1,2”，他们添加了以下代码： if (input == "1,2") return 3; 然后，他们为输入“ 4,5”引入了另一个测试，并更改了实现： if (input == "1,2") return 3; else if (input == "4,5") return 9; 之后，他们说“好的，现在我们可以看到模式了”，并执行了我最初所做的工作。 我认为第二种方法更适合TDD定义，但是...我们应该对此严格吗？对我来说，如果我确定我不会跳过任何步骤，则可以跳过琐碎的婴儿步骤并将其合并为“ twinsteps”。我错了吗？ 更新。我没有弄清楚这不是第一个测试，所以犯了一个错误。已经有一些测试，所以“返回3”实际上并不是满足要求的最简单的代码。

37 testing  tdd 

在大型，现实生活中，复杂的项目中使用TDD的一个很好的例子是什么？到目前为止，我所看到的所有示例都是出于书籍或纸张目的的玩具项目... 您能命名一个使用TDD的开源项目吗？最好使用C ++，但我可以阅读Java和C＃或其他类似语言。

37 java  c#  open-source  c++  tdd 

我正在与一个新的团队合作，该团队历来没有进行任何单元测试。我的目标是让团队最终采用TDD（测试驱动开发）作为自然过程。但是由于TDD对于非单元测试团队来说是一种根本性的转变，我想我应该从编码后编写单元测试开始。 有人遇到过类似情况吗？什么是让团队在未进行任何单元测试时对TDD感到满意的有效方法？分两步进行是否有意义？还是我们应该立即潜水并立即面对所有不断增长的痛苦？ 编辑 只是为了澄清起见，团队中除我本人之外，没有任何人可以测试暴露/经验的任何单元。我们计划使用Visual Studio中内置的单元测试功能。

37 unit-testing  tdd 

考虑一下： public function polynominal($a, $b, $c, $d) { return $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d; } 假设您为上述功能编写了各种测试，并向自己和其他人证明“它可以工作”。 为什么不删除这些测试，然后过上幸福的生活呢？我的观点是，某些功能在被证明可以正常工作后，无需对其进行连续测试。我正在寻找状态的对立点，是的，这些功能仍然需要测试，因为：...或者是的，这些功能不需要进行测试...

36 php  unit-testing  testing  tdd