4

所以，这些天我越来越沉迷于测试驱动的开发，我在思考 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”功能点编写另一个测试吗？

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

4

5 回答 5

5

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

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

链接：链接：

于 2009-03-26T00:03:46.987 回答
3

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

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

于 2009-03-25T23:57:25.440 回答
3

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

于 2009-03-25T23:59:01.787 回答
3

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

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

于 2009-03-26T00:02:46.007 回答
0

我测试大多数东西。

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

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

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

于 2013-03-26T09:53:24.353 回答