编写单元测试答案

【问题标题】：Writing unit test编写单元测试
【发布时间】：2018-07-11 07:24:40
【问题描述】：

我需要帮忙。我需要对此源代码编写一些单元测试。我试着写了它，但我没有成功。

public class PagedCollection<T> : ReadOnlyCollection<T>, 
IPagedCollection<T>

    {
        public int CurrentPage { get; }
        public int TotalPages { get; }
        public int PageSize { get; }
        public int TotalCount { get; }
        public bool HasPrevious => CurrentPage > 1;
        public bool HasNext => CurrentPage < TotalPages;

        public PagedCollection(ICollection<T> items, int count, int pageNumber, int pageSize) : base(items.ToList())
        {
            EnsureArg.IsGte(count, 0, nameof(count));
            EnsureArg.IsGt(pageNumber, 0, nameof(pageNumber));
            EnsureArg.IsGt(pageSize, 0, nameof(pageSize));

            TotalCount = count;
            CurrentPage = pageNumber;
            PageSize = pageSize;
            TotalPages = (int)Math.Ceiling(count / (double)pageSize);
        }
    }
}

谁能帮帮我？

【问题讨论】：

我假设这是 C#。如果不是这种情况，请edit 你的问题来修复标签，并且永远记得在将来添加一个语言标签。另请描述您所说的“不成功”是什么意思，并展示您尝试过的方法，以便人们可以帮助您解决问题。
您是否要对构造函数进行单元测试？构造函数不应该有业务逻辑。基于构造函数，我进行了几个测试，那些 EnsureArg 函数和 TotalPageg 计算。但是你没有提供你想测试什么的描述。
我试着写了，但没有成功。 - 你能证明你写了什么吗？你有什么具体问题吗？抱歉，但没有更具体的细节，您的问题显然仍然存在：“请为我完成我的任务”;)

标签： c# unit-testing

【解决方案1】：

第 0 步是决定你的对象应该做什么样的事情。这些东西中的每一个都成为你的测试用例。有几个明显的候选者：

[Test]
public void RejectIfCountIsZero()
{
    ICollection<string> collection = new[] { "Hello", "World" };
    ArgumentOutOfRangeException e = Assert.Throws<ArgumentOutOfRangeException>(() => { new PagedCollection<string>(collection, 0, 1, 1); });
    Assert.That(e.ParamName, Is.EqualTo("count"));
}

等其他验证

你可以测试你的总页面逻辑

[Test]
public void RoundsUpTotalPagesIfNotDivisible()
{
    ICollection<string> collection = new[] { "Hello", "World" };
    PagedCollection<string> pagedCollection = new PagedCollection<string>(collection, 100, 3, 9);
    Assert.That(pagedCollection.TotalPages, Is.EqualTo(12));
}

然后在计数可整除的情况下做一个。为您的 HasPrevious 和 HasNext 属性添加一个，期望为 true 和 false。当然，应该由构造函数初始化的属性也会被初始化。

只需测试您需要的东西，以免将来破坏（并删除您不需要的任何代码）。遵循“安排”、“行动”、“断言”的模式。使每个测试独立于其他测试。有人说每个测试一个断言，但我对此更放松一些。绝对要尽量避免通过一系列流程的测试用例。如果您发现自己需要在“安排”中调用 15 个方法才能执行“操作”，那么您的设计耦合太紧密了。

祝你好运。

【讨论】：