Questions tagged «tdd»

当我阅读Batic D的Dogsa T的先前工作的摘要时。测试驱动开发的有效性：工业案例研究。软件质量杂志。2011; 19（4）：643-661。令我惊讶的是，围绕TDD进行的许多研究中使用的度量都是基于诸如代码行，缺陷和开发时间所基于的。 是否有研究集中在使用TDD与传统开发或最后测试相比开发的产品的总拥有成本上？ 我对购置和运营总成本特别感兴趣。

11 agile  management  tdd  computer-science 

我和我的朋友是相对较新的TDD，并且对“显而易见的实现”技术存在争议（来自Kent Beck的“ TDD示例”）。我的朋友说这意味着，如果实现很明显，则应继续进行编写- 在对该新行为进行任何测试之前。确实，这本书说： 您如何实现简单的操作？只需实施它们即可。 也： 有时，您确定自己知道如何实现操作。前进。 我认为作者的意思是您应该首先进行测试，然后“实施”它，而不是“ Fake It（'Till You Make It'）”和其他技术，后者在实施阶段需要更小的步骤。同样在这些引用之后，作者谈论在执行“显而易见的实现”时获得“红条”（失败的测试）-如何在没有测试的情况下获得红条？ 但是我从书中找不到任何引述说“显而易见”仍然意味着首先要进行测试。 你怎么看？当实现是“显而易见的”时，我们应该先测试还是之后测试（当然，根据TDD）？您知道一本书或博客文章这么说吗？

11 tdd 

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

11 unit-testing  tdd 

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

11 unit-testing  tdd  code-smell  anti-patterns 

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

11 unit-testing  testing  tdd 

好像是鸡和鸡蛋的问题。 您可以使写入功能写入某些数据存储，但是在没有经过测试的读取功能的情况下，永远不会知道您是否正确保存了它。 您可以使读取功能从数据存储中读取，但是如何在没有经过测试的写入功能的情况下将东西放入该数据存储中以进行读取呢？ 编辑： 我正在连接到SQL数据库并与之进行事务，以保存和加载要使用的对象。测试数据库提供的访问功能毫无意义，但是我包装了这些数据库功能以对对象进行序列化/反序列化。我想确保我正在正确地从数据库中写入和读取正确的内容。 它不像@snowman提到的添加/删除。我想知道我写的内容是正确的，但这需要经过良好测试的读取功能。当我阅读时，我想确保我的阅读正确地创建了一个与所写内容相等的对象。但这需要经过良好测试的写入功能。

10 tdd  io 

我在Codility的一次算法测试中失败了，因为我试图找到一种更好的解决方案，最后我一无所有。 因此，这让我开始思考是否可以使用类似于TDD的方法？即我是否通常可以以类似的方式逐步开发解决方案？ 如果我正在编写排序算法，则可以从标准Bubblesort转换为2-way Bubbleort，但是诸如Quicksort之类的更高级的东西将是“量子飞跃”，但至少我拥有可以轻松验证的测试数据。 有关此类测试的其他提示？下次我要做的一件事是使用比内部循环更多的方法/函数。例如，在排序中，您通常需要交换。如果是一种方法，我只需要修改调用代码。我什至可以拥有更高级的解决方案作为派生类。 对于“算法”与“常规”问题，我指的是时间复杂性很重要的问题。因此，您不必像在TDD中那样通过更多的测试，而应使其“表现得更好”。 “类似于TDD”是指： 编写相对自动的测试以节省手动测试pr增量的时间。 增量发展。 回归测试，能够检测代码是否中断或至少在两次增量之间功能是否发生了变化。 如果您比较一下，我认为这应该很容易理解 直接编写shell排序 从Bubblesort跳到quicksort（完全重写） 从单向冒泡排序逐步转换为外壳排序（如果可能）。

10 algorithms  tdd  self-improvement 

在我的新项目中，我决定尝试使用TDD。一开始我就遇到了问题。我想在应用程序中做的第一件事就是赋予从数据源读取数据的能力。为此，我想使用存储库模式。现在： 如果测试是为了真正实现存储库接口，那么我将测试具有数据库访问权限的类，并且我知道应该避免这种情况。 如果测试不是针对存储库模式的真正实现，那么我将进行良好的测试……只是模拟。在这些单元测试中，将不会测试任何生产代码。 我从两天开始考虑这个问题，但仍然无法提出任何合理的解决方案。我该做什么？

10 tdd  patterns-and-practices  repository 

在执行TDD时会出现问题。经过几次测试通过后，某些类/模块的返回类型发生了变化。在静态类型的编程语言中，如果在其他某个类的测试中使用了先前的模拟对象，并且未对其进行修改以反映类型更改，则将发生编译错误。 但是，对于动态语言，可能无法检测到返回类型的更改，并且其他类的测试仍将通过。当然，可能会有集成测试稍后会失败，但是单元测试会错误地通过。有什么办法可以避免这种情况？ 用一个简单的示例（在某些组合语言上）更新... 版本1： Calc = { doMultiply(x, y) {return x * y} } //.... more code .... // On some faraway remote code on a different file Rect = { computeArea(l, w) {return Calc.doMultipy(x*y)} } // test for Rect testComputeArea() { Calc = new Mock() Calc.expect(doMultiply, 2, 30) // …

10 unit-testing  mocking  tdd 

如果我的代码中有一个像这样的函数： class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } 通常，我会使用工厂类和策略模式将其重构为使用多态性： public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } 现在，如果我正在使用TDD，那么calculateTax()在重构之前，我将对原始版本进行一些测试。 例如： calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} 重构后，我将具有Factory类NameHandlerFactory和的至少3个实现InameHandler。 我应该如何重构我的测试？我应该claculateTax()从中删除单元测试，EmployeeTests并为的每个实现创建一个Test类InameHandler吗？ 我也应该测试工厂课程吗？

10 design  design-patterns  unit-testing  tdd  refactoring 

有时只需要紧密耦合对象即可。例如，一个CsvFile类可能需要与CsvRecord该类（或ICsvRecord接口）紧密配合。 但是，从我过去的经验中学到，测试驱动开发的主要宗旨之一是“永远不要一次测试一个以上的类”。表示您应该使用ICsvRecord模拟或存根，而不是的实际实例CsvRecord。 但是，在尝试这种方法之后，我注意到嘲笑CsvRecord该类可能会变得有些毛茸茸。这使我得出以下两个结论之一： 编写单元测试很困难！那是代码的味道！重构！ 模拟每个依赖项是不合理的。 当我用实际CsvRecord实例替换模拟对象时，事情进行得更加顺利。当寻找其他人的想法时，我偶然发现了这篇博客文章，该文章似乎支持上面的第二点。对于自然紧密耦合的对象，我们不必太担心模拟。 我会偏离轨道吗？以上假设2有不利之处吗？我是否真的应该考虑重构设计？

10 tdd  coupling  mocking 

我有一个很大的PHP应用程序。通常有2-3个开发人员全职从事这项工作，而现在我们正在进行更改并创建错误（咳嗽功能！）。每个人说的软件并不复杂，只是发生了很多事情（35个控制器，大约相同的型号，等等）。 即使小心，更改此视图（更改元素上的id）也很容易破坏在某些特殊条件下（单脚站立时注销）发生的ajax查询。 首先想到的是单元测试，但是我们在另一个应用程序上进行了尝试，很容易忘记它们/或花更多的时间编写测试然后进行测试。我们确实有一个临时环境，可以在上线之前检查代码。 也许我们需要兼职Q / A人员？ 任何人都有任何建议/想法。

10 testing  code-quality  tdd 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 测试驱动开发意味着在代码之前和一定周期之后编写测试： 写测试 检查测试（运行） 编写生产代码 检查测试（运行） 清理生产代码 检查测试（运行） 就我而言，这只有在您的开发解决方案允许您非常快速地在生产代码和测试代码之间切换以及对特定生产代码部分执行测试的情况下才有可能。 现在，尽管存在许多C ++单元测试框架（我正在使用Bost.Test atm。）看来，实际上并没有任何像样的（对于本机C ++而言）Visual Studio（插件）解决方案能够使TDD周期可承受，与使用的框架无关。 “可以承受”表示只需单击一下即可对某个cpp文件运行测试，而无需手动设置单独的测试项目等。“可以承受”还表示一个简单的测试开始（链接！）并且运行非常快。 那么，有哪些工具（插件）和技术可以使使用Visual Studio进行本机C ++开发的TDD周期成为可能？ 注意：我可以使用免费或“商业”工具。 请：没有框架建议。（除非框架具有专用的Visual Studio插件，并且您要推荐该插件。） 编辑说明：到目前为止的答案提供了有关如何将单元测试框架集成到Visual Studio中的链接。这些资源或多或少描述了如何获取UT框架进行编译以及如何运行您的第一个测试。这不是这个问题的意思。我认为要真正有效地工作，将单元测试放在手动维护（！）中，将vcproj与您的生产类分开会增加太多开销，以致TDD“不可能”。据我所知，您没有为Java或C＃事物添加额外的“项目”以启用单元测试和TDD，这是有充分的理由的。这应该 只要有正确的工具，C ++就可以实现，但似乎（这个问题是关于）TDD / C ++ / VS的工具很少。 到处搜寻，我发现一个工具VisualAssert似乎朝着正确的方向发展。但是，afaiks，它似乎并未得到广泛使用（与CppUnit，Boost.Test等相比）。 编辑：我想在此问题的上下文中添加评论。我认为它很好地概括了问题的一部分：（Billy ONeal的评论） Visual Studio不使用用户可以合理编辑的“构建脚本”。一个项目产生一个二进制文件。而且，Java具有Java从不构建完整二进制文件的特性-您构建的二进制文件只是类文件的ZIP。因此，可以分别手动编译然后JAR一起编译（使用例如7z）。C ++和C＃都实际上链接了它们的二进制文件，因此，一般来讲，您不能编写这样的脚本。最接近的是分别编译所有内容，然后进行两个链接（一个用于生产，一个用于测试）。

10 ide  tdd  plugins  visual-c++ 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 TDD专家越来越多地告诉我们TDD与测试无关，而与设计有关。因此，我知道有些开发人员在没有TDD的情况下创建了非常出色的设计。他们应该练习TDD吗？

10 tdd 

我是一个开发团队的成员，该团队与许多其他团队一起维护和改进已使用了至少15年的应用程序。最初构建和设计TDD时闻所未闻。 该应用程序相当稳定，我们很少遇到显示错误，但是我们每周平均会发现大约一两个错误，这严重降低了服务质量。这些错误要花很长时间才能找到并修复，这在很大程度上是因为手指指向的，而我们仅有的测试是接口测试。因为在修复该错误之前浪费了很多时间，所以我和另一个开发人员计划提出测试驱动开发。即将进行新的大修，我们希望在新模块上完成几乎完整的单元测试，我们还计划建议为我们必须更改的任何遗留代码（例如，错误修复或功能实现）构建测试单元。 ），但不要花时间为尚未引起问题的代码开发测试用例。 对我来说，这似乎是合理的。本月，我们修复了一个错误，该错误花费了两周的时间，但是如果完成了单元测试，则可以在部署之前发现该错误。但是对于我们的经理们来说，他们好像要花更多的钱。 我如何说服我们的客户他们想花钱进行单元测试和测试驱动的开发？是否有任何研究表明单元测试的投资回报率？

10 unit-testing  tdd