当前位置：文江博客话题详情

有人能解释一下“假装直到成功”吗？测试驱动开发中的方法？

发布于 2024-10-02 07:18:48 字数 226 浏览 3 评论 0原文

当您采用“Fake It Until You Make IT”TDD 方法时，我很难理解代码的演变。

好吧，你伪造了它，假设你返回了一个常量，以便损坏的测试一开始是绿色的。然后你重构了你的代码。然后你运行相同的测试，显然它会通过，因为你伪造了它！

但如果测试通过了，你怎么能相信它，特别是当你知道你伪造了它时？

应该如何用真实的代码重构来重构伪造的测试，使其仍然可靠？

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一个人练习一个人 2024-10-09 07:18:48

简短的答案是：编写更多测试。

如果该方法返回一个常量（当它应该计算某些内容时），只需添加对具有不同结果的条件的测试即可。因此，假设您有以下内容：

@Test
public void testLength()
{
    final int result = objectUnderTest.myLength("hello");
    assertEquals(5, result);
}

并且 myLength 被实现为 return 5，然后您编写一个类似的（附加）测试，但传入相反，并断言输出为 6。

当您编写测试时，您应该尝试对实现非常报复，并尝试编写一些暴露其缺点的内容。当您编写代码时，我认为您应该非常自由放任，并且只需要做很少的事情即可使那些令人讨厌的测试变得绿色。

The short answer is: write more tests.

If the method is returning a constant (when it should be calculating something), simply add a test for a condition with a different result. So, let's say you had the following:

@Test
public void testLength()
{
    final int result = objectUnderTest.myLength("hello");
    assertEquals(5, result);
}

and myLength was implemented as return 5, then you write a similar (additional) test but pass in "foobar" instead and assert that the output is 6.

When you're writing tests, you should try to be very vindictive against the implementation and try to write something that exposes its shortcomings. When you're writing code, I think you're meant to be very laissez-faire and do as little is required to make those nasty tests green.

回复收藏 0 原文

心在旅行 2024-10-09 07:18:48

您首先创建一个单元测试来测试不存在的新功能。

现在，您对一个不存在的方法进行了单元测试。然后，您创建不执行任何操作的方法，并且单元测试可以编译，但当然会失败。

然后，您继续构建方法、底层功能等，直到单元测试成功。

这就是（某种）测试驱动开发。

您应该能够信任这一点的原因是您应该进行单元测试，以便它真正测试您的功能。当然，如果它只返回一个常量并且您只是对其进行测试，那么您就会遇到问题。但是，你的单元测试还没有完成。

您的单元测试应该（理论上）测试每一行。如果你做得很好，那么这应该可行。

回复收藏 0 原文

饮惑 2024-10-09 07:18:48

假装它直到你做到它说要编写尽可能简单的东西来通过当前的测试。通常，当您为新功能编写单个测试用例时，最简单的可能就是返回一个常量。当如此简单的东西满足您的测试时，那是因为您（还）没有足够的测试。因此，正如 @Andrzej Doyle 所说，编写另一个测试。现在您正在开发的功能需要一些逻辑。也许这次最简单的事情就是编写非常基本的 if-else 逻辑来处理两个测试用例。你知道你在假装，所以你知道你还没有完成。当编写实际代码来解决您的问题比扩展您的假代码以覆盖另一个测试用例变得更简单时 - 这就是您所做的。并且您有足够的测试用例来确保您正确编写它。

回复收藏 0 原文