测试写作策略建议

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上:

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

链接:链接: