如何为返回列表的方法创建适当的单元测试？

Question

我有这个方法:

public DataSourceResult GetProjectBySpec(int projectId, int seasonId, int episodeId)
        {
            using (var rep = RepositoryHelper.GetTake2Repository<ITake2RepositoryBase>())
            {
                var spec = new ProjectCrewsByProjectSpec(projectId, seasonId, episodeId);

                var personList = rep.GetList<ProjectDGACrew>(spec).Select(p => new
                {
                    //big query...
                    .ToDataSourceResult();

                return personList;
            }
        }

我需要为此创建一个单元测试.

我的第一个问题是:

1. 我在测试什么？我是否仅测试该方法是否返回列表？

2. 如果是这样,我将如何进行测试呢？

这是我到目前为止:

    [TestClass]
    public class CrewControllerTest
    {
        [TestMethod]
        public void GetProjectCrewsBySpecTest()
        {
            // arrange
            int projectId = 1;
            int seasonId = 2;
            int episodeId = 3;

            // act
            var crewController = new CrewController();
            DataSourceResult dsr = crewController.GetProjectCrewsBySpec(1, 2, 3);

            // assert
            // what or how do I assert here? Am I just checking whether "dsr" is a list? How do I do that?
        }
    }

Answer 1

我也不是专家，而且我只做了一小段时间 TDD，所以请接受我在这个漫无目的的答案中写的内容：）我相信其他人可以指出我是否真的做了任何事情严重的错误或给你指明了错误的方向......

我不确定您的测试是否真的是单元测试，因为它正在执行多个依赖项。假设您运行此测试并从该方法中抛出异常。这个异常是来自于

• RepositoryHelper.GetTake2Repository()) 抛出？（依赖问题）
• ProjectCrewsByProjectSpec 构造函数抛出异常？（依赖问题）
• rep.GetList(spec) 抛出？剑道（是剑道，对吧？）（依赖问题）
• ToDataSourceResult() 抛出？（行为问题）

单元测试就是在与依赖项完全隔离的情况下测试事物，因此目前我认为它更像是集成测试，您并不真正关心系统如何交互，您只想确保对于给定的projectID、seasonId 和 EpisodeId 你会得到预期的结果 - 在这种情况下真正测试的是与.rep.GetList()方法结合使用的。ToDataSourceResult扩展。

现在，集成测试非常非常有用，并且作为测试驱动方法的一部分是 100% 必需的，如果这是您真正想做的，那么您就做得对了。（我将其放入并期望返回；我是吗？拿回来吗？）

但是，如果您想对这段代码进行单元测试（具体来说，如果您想对类的GetProjectBySpec方法进行单元测试），您将必须按照 @jimmy_keen 提到的方法进行重构，以便可以测试GetProjectBySpec 的行为。例如，这是我刚刚发明的指定行为，当然你的可能会有所不同：

• 如果输入错误，则抛出 ArgumentException
• 创建一个新的 ProjectCrewsByProjectSpec 对象
• 调用rep.GetList并将spec传递给它
• 返回一个非空的 DataSourceResult

为了能够测试 GetProjectBySpec 执行上面列表中的所有操作，您需要做的第一件事是重构它，以便它不会创建自己的依赖项 - 相反，您为其提供所需的依赖项，通过依赖注入。

当您通过接口注入时，DI 确实效果最好，因此在任何提供此方法的类中，该类的构造函数都应该采用IRepositoryHelper的实例并将其存储在私有只读成员中。它还应该采用IProjectCrewsByProjectSpecFactory的实例，您可以使用它来创建规范。现在，既然您想测试 GetProjectBySpec 对这些依赖项的实际作用，那么您将使用模拟框架，例如Moq，除了下面的示例之外，我不会在这里讨论它。

如果这些类当前都没有实现这样的接口，那么只需使用 Visual Studio 根据类定义为您提取接口定义。如果它们是您无法控制的第三方类，这可能会很棘手。

但是让我们假设一下，您可以这样定义接口：（请耐心等待我从未 100% 同意的通用 <> 位，我相信比我更聪明的人可以告诉您所有“T”的位置应该去...）下面的代码未经测试，也没有检查拼写错误！

public interface IRepositoryHelper<ProjectDGACrew>
{
  IList<ProjectDGACrew> GetList(IProjectCrewsByProjectSpecFactory spec);
}

public interface IProjectCrewsByProjectSpecFactory 
{
 ProjectDGACrew Create(int projectId, int seasonId, int episodeId);
}

然后你的代码最终会看起来像这样：

//somewhere in your class definition
private readonly IRepositoryHelper<T> repo;
private readonly IProjectCrewsByProjectSpecFactory pfactory;
//constructor
public MyClass(IRepositoryHelper<ProjectDGACrew> repo, IProjectCrewsByProjectSpecFactory pfactory)
{
this.repo = repo;
this.pfactory=pfactory;
}
//method to be tested
public DataSourceResult GetProjectBySpec(int projectId, int seasonId, int episodeId)
{
            var spec = pfactory.Create(projectId, seasonId, episodeId);
            var personList = repo.GetList(spec).Select(p => new
                {//big query...}).ToDataSourceResult();
                return personList;
}

现在你有 4 个测试方法要写：

[TestMethod]
[ExepctedException(typeof(ArgumentException)]
public void SUT_WhenInputIsBad_ThrowsArgumentException()
{
    var sut = new MyClass(null,null); //don't care about our dependencies for this check
    sut.GetProjectBySpec(0,0,0); //or whatever is invalid input for you.
    //don't care about the return, only that the method throws.
}



[TestMethod]
public void SUT_WhenInputIsGood_CreatesProjectCrewsByProjectSpec()
{
  //create dependencies using Moq framework.
  var pf= new Mock<IProjectCrewsByProjectSpecFactory>();
  var repo = new Mock<IRepository<ProjectDgaCrew>>();
  //setup such that a call to pfactory.Create in the tested method will return nothing
  //because we actually don't care about the result - only that the Create method is called.
  pf.Setup(p=>p.Create(1,2,3)).Returns<ProjectDgaCrew>(new ProjectDgaCrew());
  //setup the repo such that any call to GetList with any ProjectDgaCrew object returns an empty list
//again we do not care about the result. 
//This mock dependency is only being used here
//to stop an exception being thrown from the test method
//you might want to refactor your behaviours
//to specify an early exit from the function when the factory returns a null object for example.
   repo.Setup(r=>r.GetList(It.IsAny<ProjectDgaCrew>()).Returns<IList<ProjectDGACrew>>(new List<ProjectDgaCrew>());
  //create our System under test, inject our mock objects:
   var sut = new MyClass(repo,pf.Object);
   //call the method:
   sut.GetProjectBySpec(1,2,3);
   //and verify that it did indeed call the factory.Create method.
    pf.Verify(p=>p.Create(1,2,3),"pf.Create was not called with 1,2,3");              
}
        public void SUT_WhenInputIsGood_CallsRepoGetList(){} //you get the idea
        public void SUT_WhenInputIsGood_ReturnsNonNullDataSourceResult(){}//and so on.

希望这能给您一些帮助......当然您可以重构您的测试类以避免大量模拟设置并将其全部放在一个位置以将代码行数保持在最低限度。