public ApplicationLayout Get(string objectName, string userName)
{
using (var db = new SqlConnection(_connectionString))
{
var sql = "SELECT * FROM dbo.ApplicationLayout WHERE ObjectName = @ObjectName AND UserName=@UserName";
return db.Query<ApplicationLayout>(sql, new {ObjectName = objectName, UserName = userName}).FirstOrDefault();
}
}
我这里有一些代码，我想知道是否可以使用 SQL 数据(任何框架)在 C# 中执行单元测试。从我所看到的，这是不可能的。任何人都可以确认这一点吗？
我总是在专用数据库上进行测试。您可以进行设置和拆卸，并且基本上每次运行这些测试时都会重新创建数据库(或从备份还原数据库)。它比普通的 C# 单元测试要复杂得多。就像一些评论所说的那样，它不再是真正的单元测试，而是需要以一种或另一种方式进行测试的东西。
可能，但不建议用于单元测试。
当你谈论单元测试时，你通常谈论的是一个可以单独重复执行的测试;也就是说，它在它所在的代码程序集之外没有依赖关系(理想情况下，每个测试不应该远远超出被测试的单个类)，并且无论测试如何启动或停止都没有持久的副作用(不需要使用文件系统， 或数据库等)。这是因为单元测试是最小和最细粒度的测试，旨在测试您自己编写的代码。您没有编写 SQL Server，因此 SQL Server 不应在单元测试的范围内。
现在，一旦您将范围扩大到集成测试和验收测试，现在您正在测试您编写的代码是否可以很好地与未编写的所有外部依赖项配合使用。集成测试可以接触外部数据，如数据库，并且可以写入和读取这些外部存储，只要它们正确清理自己，要么在运行后将持久数据库返回到其原始状态，要么只是使用可移植数据库，如 SQLite 或 MSS Express，设置必要的模式和测试数据作为测试设置的一部分， 然后在完成后将数据库吹走。
对于许多人来说，这是分裂头发，像 MSTest 或 NUnit 这样的单元测试框架不会阻止您使用它们来创建具有外部依赖项的测试。这些只是将整个测试套件构建为细粒度、快速运行、可重复的组件的好主意，您可以在所做的任何更改上运行该组件，以及可能在一夜之间运行的时间更长、范围更广的正确性证明。
针对真实 SQL 引擎编排测试的现代方法必须有效：
- 在开发机器(运行Windows，MacOS或Linux)上本地;
- 在云中构建管道(例如 Azure DevOps 管道、GitHub 操作、 等)。
TL;DR– 在 GitHub 上查看 DbSample，这是一个基于 EF Core 的示例 针对 MS SQL Server 和 GitHub 进行全自动测试的项目 操作管道。
编排测试的详细分析在"Pain & Gain of Automated tests Against SQL (MS SQL， POSTGRESQL)"一文中介绍。关键步骤是：
- 在Docker中启动SQL引擎(使用SQL Server或PostgreSQL的官方镜像)
- 创建测试数据库并填充架构、逻辑、查找字典等(通过容器的命令行)
- 将 xUnit/NUnit 测试连接到数据库，对于每个测试(冲洗并重复)：
- 种子测试数据
- 执行可测试的活动和检查
- 将数据库恢复到原始状态(通过重生)
- 拆除 SQL 引擎以及数据库和其他工件。
附言我知道，OP 说的是">单元测试"，但也许意味着更广泛的">自动化测试">