基于TDD设计MVC数据库调用控制器及单元测试配置咨询

嘿，作为MVC和单元测试的新手，你发现的问题其实是硬依赖导致无法隔离测试——你的控制器直接在方法里new MyLocations()，这就把它和真实的数据获取逻辑绑死了，没法在测试时替换成静态数据。咱们一步步重构，让它适合TDD：

第一步：抽象数据获取逻辑（解耦） #

首先，把MyLocations的核心功能抽象成一个接口，这样我们就能在测试时用假的实现来替代真实的：

// 定义接口，描述数据获取的契约
public interface ILocationProvider
{
    IEnumerable<Location> GetLocations();
}

// 让原有的MyLocations实现这个接口
public class MyLocations : ILocationProvider
{
    public IEnumerable<Location> GetLocations()
    {
        // 这里保留你原来的真实数据获取逻辑（比如从DB/API拉取）
    }
}

第二步：重构控制器，用依赖注入接收依赖 #

把控制器里直接new的逻辑改成通过构造函数注入上面的接口，这样控制器不再关心数据从哪来，只关心怎么处理：

public class MyController : Controller
{
    // 用私有字段保存依赖
    private readonly ILocationProvider _locationProvider;

    // 构造函数注入，确保控制器拿到需要的依赖
    public MyController(ILocationProvider locationProvider)
    {
        // 加个空值检查，避免传入null
        _locationProvider = locationProvider ?? throw new ArgumentNullException(nameof(locationProvider));
    }

    public ActionResult Index(int id)
    {
        // 现在从注入的依赖获取数据，而不是直接new
        var locations = _locationProvider.GetLocations();
        // 你的过滤Linq代码
        var filteredLocations = locations.Where(loc => loc.Id == id); // 示例过滤逻辑，替换成你的实际代码
        return View(filteredLocations);
    }
}

第三步：编写单元测试，用静态数据测试 #

现在你可以轻松在测试中提供静态数据了——要么用Mock框架（比如Moq），要么手动写一个测试用的ILocationProvider实现。

方法1：用Moq框架快速Mock静态数据 #

using Moq;
using Xunit; // 或者你用的测试框架，比如NUnit/MSTest

public class MyControllerTests
{
    [Fact]
    public void Index_WithValidId_ReturnsFilteredLocations()
    {
        // Arrange：准备测试数据和Mock依赖
        var testLocations = new List<Location>
        {
            new Location { Id = 1, Name = "纽约" },
            new Location { Id = 2, Name = "伦敦" },
            new Location { Id = 1, Name = "洛杉矶" }
        };

        // 创建ILocationProvider的Mock，让它返回我们的静态数据
        var mockProvider = new Mock<ILocationProvider>();
        mockProvider.Setup(p => p.GetLocations()).Returns(testLocations);

        // 实例化控制器，传入Mock的依赖
        var controller = new MyController(mockProvider.Object);

        // Act：调用要测试的方法
        var result = controller.Index(1) as ViewResult;
        var model = result?.Model as IEnumerable<Location>;

        // Assert：验证结果是否符合预期
        Assert.NotNull(result);
        Assert.NotNull(model);
        Assert.Equal(2, model.Count()); // 应该返回2条id=1的记录
    }
}

方法2：手动写测试实现（不用Mock框架） #

如果你暂时不想用Mock框架，可以写一个专门用于测试的ILocationProvider：

// 测试用的实现，接收静态数据并返回
public class TestLocationProvider : ILocationProvider
{
    private readonly IEnumerable<Location> _testData;

    public TestLocationProvider(IEnumerable<Location> testData)
    {
        _testData = testData;
    }

    public IEnumerable<Location> GetLocations()
    {
        return _testData;
    }
}

然后在测试中使用：

[Fact]
public void Index_WithValidId_ReturnsFilteredLocations()
{
    // Arrange
    var testData = new List<Location> { /* 你的静态测试数据 */ };
    var testProvider = new TestLocationProvider(testData);
    var controller = new MyController(testProvider);

    // Act
    var result = controller.Index(1) as ViewResult;
    var model = result?.Model as IEnumerable<Location>;

    // Assert
    Assert.NotNull(model);
    Assert.Equal(2, model.Count());
}

为什么这么做？ #

这样调整后，你的控制器和数据获取逻辑完全解耦了：

• 真实环境中，你可以通过DI容器（比如ASP.NET Core自带的DI）注入MyLocations；
• 测试时，你可以完全控制输入的静态数据，不用依赖数据库、API等外部资源，测试更快、更可靠，完美适配TDD模式——你可以先写测试定义预期行为，再实现控制器的过滤逻辑。

内容的提问来源于stack exchange，提问作者Legionpete