我对单元测试有疑问。目前我有一个大型项目，调用许多SP，并没有获得大多数方法的回报。它确实是许多SQL调用的大包装器。没有很多逻辑，因为它全部保存在SP中，它也有部分内联sql。
我需要对这个c＃项目进行单元测试，但是很明显单元测试是没有意义的，因为它会调用许多SP，这些都会被嘲笑。我担心我的想法不正确。
我的问题是，有没有人遇到过这个问题，他们做了什么？我是否应该进行数据库单元测试，任何见解都会有很大的帮助。
感谢。
答案 0 :(得分：0)
单元测试不应该触及数据访问层，因为这将是集成测试/系统测试。您可以测试的是您的项目实际上调用了您的数据访问层。这样做可以让您高枕无忧，在单击按钮的重构期间始终会调用数据访问层。
//Arrange
var dataAccessMock = new Mock<IDataAccessMock>();
dataAccessMock(da => da.ExecuteSomething());
IYourApplication app = new YourApplication(dataAccessMock);
//Act
app.SomeProcessThatCallsExecuteSomething("1234567890");
/Assert
dataAccessMock.Verify(dp=>da.ExecuteSomething(), Times.Once());
请注意，在此示例中，我使用的是Moq
根据您的喜好对此进行测试后，您可以专注于集成测试，以验证存储过程是否按预期工作。为此，您可能需要做很多工作才能将数据库附加到已知状态，运行存储过程，然后还原或删除数据库，以便测试可重复。
答案 1 :(得分：0)
您应该将测试策略分为集成测试和单元测试。
对于集成测试，您可以依赖现有数据库。您通常会在此处编写更多高级测试，并验证您的应用程序是否正确地与您的数据库进行交互。
对于单元测试，您应该只选择实际上对于模拟有意义的选定方案。这些通常是许多业务逻辑“位于数据库逻辑顶部”并且您希望验证业务逻辑的情况。 随着时间的推移，您可以模拟越来越多的数据库调用，但是一开始就确定关键点。
答案 2 :(得分：0)
您已经发现业务逻辑通常应该进入业务的一个原因，而不是数据访问层。当然，有一些例外由性能和安全问题决定，但它们应该仍然是例外。
话虽如此，你仍然可以制定一个测试你的sprocs的策略（虽然取决于它们有多广泛，将这些测试称为“单元测试”可能也可能不正确。）
您可以使用单元测试框架。
在初始化部分中，将数据库的测试副本还原到已知状态，例如，通过从以前保存的副本加载它。
然后，执行执行存储过程的单元测试。由于存储过程通常不返回任何内容，因此单元测试代码必须从数据库中选择值以检查是否进行了预期的更改。
根据存储过程之间可能的交互，可能有必要在每个测试之间或相关测试组之间恢复数据库。
答案 3 :(得分：0)
数据/持久层可能是单元测试视角中经常被忽视的代码（使用测试双精度的真实单元测试：模拟，存根，假货等）。如果要连接到数据库，那么就是集成测试。我发现a）良好的架构数据/持久层有价值，因为副作用很容易测试（使用接口，良好的数据访问框架抽象等等，而b）实际上是单元和集成测试属性。