测试写作策略建议答案

【问题标题】：Test writing strategy advice测试写作策略建议
【发布时间】：2010-10-15 14:26:43
【问题描述】：

因此，这些天来，我越来越沉迷于测试驱动的开发，我在考虑 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();
    }
}

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

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

您是否设置了测试以防您将来扩展该功能？还是你觉得这里的测试太过分了？

【问题讨论】：

标签： c# unit-testing tdd test-first

【解决方案1】：

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

“我会为有效的代码而不是测试获得报酬，因此我的理念是尽可能少地进行测试以达到给定的信心水平（我怀疑与行业标准相比，这种信心水平很高，但这可能只是狂妄自大）。如果我通常不会犯某种错误（例如在构造函数中设置错误的变量），我不会对其进行测试。“

链接：Link:

【讨论】：

这正是我被它绊倒的那种想法。从商业角度来看，我上面写的案例似乎很难证明是正确的。但就个人而言，我想知道这是否是一个好习惯。
我自己已经非常沉迷于单元测试。但是，像你一样，我怀疑我做的太多了。看到肯特的话只会加深这种感觉。我不知道它会如何动摇......仍在考虑。
只直接测试功能；功能将间接测试其他所有内容。

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

事后编写测试很好！如果您首先实现这些功能然后对其进行测试，那会感觉很奇怪。这就是为什么您应该首先编写测试然后实现功能的原因。此外，这将迫使您考虑如何使用您的功能。此外，如果您首先实现您想要实现的任何东西，您会发现自己处于代码难以测试的情况。再一次，测试优先的方法对此有所帮助，如果您在实际实现函数之前先实现测试，代码将更具可测试性。

【讨论】：

【解决方案4】：

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

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

【讨论】：

【解决方案5】：

我测试大多数东西。

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

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

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

【讨论】：