我也不是专家，而且我只是做了一小段时间 TDD，所以用一勺盐来接受我在这个漫无边际的答案中写的内容 :) 我相信其他人可以指出我是否已经犯了任何非常严重的错误或将您指向错误的方向...
我不确定您的测试是否真的是单元测试，因为它正在执行多个依赖项。假设您运行此测试并从方法中抛出异常。
这个异常是否来自
- RepositoryHelper.GetTake2Repository())
投掷？ （依赖问题）
- ProjectCrewsByProjectSpec 构造函数抛出？ （依赖问题）
- rep.GetList(spec) 抛出？剑道（它是
剑道，对吧？）（依赖问题）
- ToDataSourceResult() 抛出？ （行为问题）
单元测试就是在完全独立于它们的依赖项的情况下测试事物，所以目前我想说它更像是一个集成测试，您并不真正关心系统如何交互，您只想确保对于给定的 projectID、seasonId 和 episodeId，您可以获得预期的结果 - 在这种情况下，真正测试的是 rep.GetList()方法结合 .ToDataSourceResult 扩展。
现在集成测试非常有用，并且 100% 需要作为测试驱动方法的一部分，如果那是你真正想做的，那么你做的就是正确的。（我把 这个 em> 并期待 that 回来；我得到 that 回来了吗？）
但是如果你想单元测试这段代码（特别是，如果你想对你的类的 GetProjectBySpec 方法进行单元测试）你必须按照@jimmy_keen 提到的那样做并重构它，以便您可以测试 GetProjectBySpec 的行为。
例如这是我刚刚发明的一个特定行为，当然你的可能会有所不同：
- 如果输入错误，抛出 ArgumentException
- 创建一个新的 ProjectCrewsByProjectSpec 对象
- 调用 rep.GetList 并将规范传递给它
- 返回非 null DataSourceResult
为了能够测试 GetProjectBySpec 是否完成了上面列表中的所有事情，您需要做的第一件事是重构它，以便它不会创建自己的依赖项 - 相反，您给它提供依赖项它需要，通过Dependency Injection。
当您通过接口注入时，DI 确实效果最佳，因此在任何提供此方法的类中，该类的构造函数都应采用例如 IRepositoryHelper 的实例并将其存储在私有只读成员中.它还应该采用 IProjectCrewsByProjectSpecFactory 的实例，您将使用它来创建规范。现在，既然您想用这些依赖项测试 GetProjectBySpec 的实际操作，那么您将使用诸如 Moq 之类的模拟框架，除了下面的示例外，我不会在这里介绍它。 p>
如果这些类目前都没有实现这样的接口，那么只需使用 Visual Studio 根据类定义为您提取接口定义。如果它们是您无法控制的第 3 方类，这可能会很棘手。
但是让我们假设您可以这样定义接口：（请耐心等待我从来没有 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.
希望能给您一些帮助...当然，您可以重构您的测试类以避免大量的模拟设置，并将所有这些设置在一个地方以将代码行数保持在最低限度。