Question

所以，这些天我越来越多地被测试驱动的开发所吞噬，而且我在思考tdd时编写的代码越多，看起来就像我必须考虑应该编写的测试程度一样。我想就我自己的项目应该为单位测试编写多少个人策略，并且想知道我是否会就你们采取什么样的方法得到一些建议。

这是我目前面临的一个决定的例子......

我有三节课......

public class User
{
    public string Username { get; set; }
    public List<Favorite> Favorties { get; set; }
}

public class Favorite
{
    public string Username { get; set; }
    public int rank { get; set; }
}

public class UserManager
{
    public List<Favorite> GetTop5(User user)
    {
        var qry = from fav in user.Favorties.OrderBy(f => f.rank)
                  select fav;

        return qry.Take<Favorite>(5).ToList();
    }
}

我有一个User类的数据访问层，我已经有了一个“GetUser”测试设置。正如您所看到的，在我的业务逻辑中，我有一个方法UserManager.GetTop5（），它返回我刚从数据库中取出的用户的前5个收藏夹。此方法非常简单，目前不涉及任何外部资源或依赖项。

所以我的问题是你会继续为这个“GetTop5”功能点编写另一个测试，即使失败的可能性很小吗？

如果您将来扩展功能，您是否设置了测试？或者你认为这里的测试是否过度？

Answer 1

你不会相信这一点，但这是Kent Beck不得不说的，就在StackOverflow上：

“我得到的代码是有效的，而不是测试，所以我的理念是尽可能少地测试以达到给定的置信水平（我怀疑这种信心水平与行业标准相比很高，但那可能如果我通常不会犯一个错误（比如在构造函数中设置错误的变量），我就不会测试它。“

链接：Link:

Answer 2

在进行TDD时，我为每个功能编写至少一个单元测试。

那么，GetTop5是一个功能吗？如果是这样，它值得一试。如果它不是一个特征，那么就不需要存在; - ）

Answer 3

之后写测试的好点！如果你首先实现这些功能，然后对它们进行测试，那就觉得奇怪这就是为什么你应该首先编写测试然后实现这些功能。此外，这将迫使您考虑如何使用您的功能。此外，如果您首先实现您想要实现的任何内容，您将发现自己处于代码难以测试的情况。再次测试第一种方法有助于此，如果您在实际执行函数之前开始实施测试，代码将更加可测试。

Answer 4

是的我也会为该方法编写一个测试，一般来说，您应该测试您实现的功能。记住TDD不仅仅用于测试该方法是否有效，还应该测试它如何处理异常，例如，如果将Null作为用户对象，会发生什么。

使用TDD进行开发时，您实际上正在设计团队中其他成员必须使用的API，因此TDD允许您编写您希望如何使用API，这意味着如何调用它以及如何调用错误处理。对于更复杂的方法，您可能希望返回自己的自定义异常，以便更清楚地发生错误。

Answer 5

我测试了大多数东西。

每当我编写测试时，我也会将测试视为文档或有关如何使用我的代码的说明，以供我和其他人在将来阅读。

我不测试实现。我希望能够在不改变测试的情况下更改实现。

我使用TDD可能需要一两年，所以也许我会成熟并停止。不过到目前为止，我还在学习并认为我没有写足够的测试。

测试写作策略建议

5 个答案: