-3

我必须编写一个java程序，并证明我在编写程序时使用了TDD。我需要找到一些方法来证明测试驱动开发的使用，这意味着以某种方式记录一些测试的失败，然后记录一些代码的编写，然后记录通过的测试，等等。欢迎任何帮助。此外，任何与 java 相关的 TDD 文档资源都会有所帮助！谢谢！

4

3 回答 3

1

就个人而言，我不同意您应该根据他们是否使用 TDD 来判断开发人员。这就像判断一名前锋的运球技巧一样。唯一重要的是他们是否帮助他们的球队获胜或打进了足够多的进球。与运球一样，TDD 是一种手段，而不是目的。由于它本身不是一个目标，因此无需测试您在开发应用程序时是否使用过 TDD。如果您认为 TDD 可以帮助您创建可维护、经过测试和面向未来的解决方案，那么您决定使用 TDD，这应该是您的目标。如果您可以使用其他一些技术获得相同的结果，那么结果应该不言自明。话虽如此，TDD 是迄今为止实现上述品质的最流行和经过验证的技术。因此，您可以测试某人是否熟练通过测量结果的质量来使用 TDD（或同样有效的技术）。TDD 只是一个工具，与任何其他工具一样，您需要练习才能正确使用它。糟糕的 TDD 会导致糟糕的设计以及一堆无用的测试。

测试是否有人使用 TDD 或同样有效的流程：

  • 运行静态分析（例如sonar、qulice等）并将结果与​​一些参考项目进行比较（有好的和坏的设计，因为你需要一些基准）。TDD 提供了一个反馈循环，可帮助您交付设计良好的软件。糟糕的设计清楚地表明没有使用 TDD，或者该人不知道如何使用 TDD 提供的反馈。
  • 运行突变测试（例如ptest），并如上所述，将结果与一些经过良好测试和较差测试的参考项目进行比较。100% 的覆盖率不是 TDD 的目标。但是，它的目标之一是通过提供有价值的测试套件和自我记录的代码，让您有信心更改和改进您的代码。应用TDD 三定律的副作用是代码覆盖率非常高。我鼓励您使用突变框架，而不仅仅是覆盖分析。变异测试检查测试套件是否真正测试了行为（而不仅仅是执行代码行以实现高覆盖率）。

如果根据上面的检查，项目的设计很好，测试也很好，你可以出于好奇询问作者是否使用了TDD，但这应该不会影响你的判断。相反，如果设计很好，并且项目在没有使用 TDD 的情况下经过了良好的测试，那么您就有机会发现新工具并将其添加到您的工具箱中，以帮助您实现作为开发人员的目标。

于 2018-03-31T19:42:30.263 回答
0

测试驱动开发更多的是一种开发方法论。

Kent Beck的参考书通过示例定义了 TDD。从字面上看，你无法证明 TDD 的使用。引用作者的话，TDD 是一组暗示“红/绿/重构——TDD 口头禅”的规则。也就是说：

  1. Red-Write 一个不起作用的小测试，并且可能一开始无法编译
  2. 绿色——让测试快速工作，在这个过程中犯下任何必要的罪过
  3. 重构——消除仅仅让测试工作产生的所有重复

这不会是一个证明机器人，只是对您的工作的跟踪：对于第 1 点和第 2 点，您可以记录 JUnit 测试的结果以显示红色和绿色之间的序列（假设在第 1 点，您的测试已编译）。

第三点，这是关于重构的度量。诸如Sonar之类的工具可以为您提供重复测量。为此，简单的方法是使用Maven管理项目，这应该有助于编写 JUnit 测试。通常，项目是使用 Jenkins 或 Hudson 等持续集成工具构建的。

于 2014-11-09T21:27:14.527 回答
0

我可以建议您阅读由 Viktor Farcic、Alex Garcia 撰写的 Test-Driven Java Development - Second Edition。这是一本了不起的书。

  • 探索有效的 TDD 开发所需的工具和框架
  • 高效执行 Red-Green-Refactor 流程，这是所有其他 TDD 程序所依据的支柱
  • 独立于其余代码掌握有效的单元测试
  • 通过实施不同的技术设计简单且易于维护的代码
  • 使用模拟框架和技术轻松编写和快速执行测试
  • 结合单元测试开发一个应用程序来实现行为驱动的开发
  • 使用功能切换启用和禁用功能
于 2019-09-22T16:20:33.107 回答