为了在SQL Server和C#之间进行交互,我正在使用SqlCommand对象,参数和存储过程。
我的问题是我不知道,直到我执行它,如果它仍然与数据库同步。
例如,如果我有以下存储过程:
create procedure psSync
(
@Argument VARCHAR(50)
)
--do stuff
我将在我的代码中:
String myArgument="20131110"
SqlCommand sqlcmd = new SqlCommand { CommandType = CommandType.StoredProcedure, CommandText = "psSync"};
sqlCommand.Parameters.AddWithValue("@Argument", myArgument);
//execute sql command
这里的一切都很好。
但如果我将我的过程改为
create procedure psSync
(
--Desync!
@Argument Datetime
)
--do stuff
忘记将myArgument更改为datetime,它会崩溃,而且我经常会注意到这个bug太迟了。
我首先尝试运行单元测试,使用begin transaction和rollback在我的开发数据库中执行存储过程,但我不喜欢它:
所以我的问题是:
如何快速,高效,安全地测试C#代码和SqlServer代码(SqlCommand->存储过程)之间的所有sql链接?
答案 0 :(得分:0)
好奇,为什么要添加那种架构验证? 正确地改变过程参数不会发生这种情况。谁正在修改必须意识到这也需要更改代码。
但是如果您遇到任何情况并且确实需要这样做,您必须提出自己的框架或API集,您可以在实际调用数据库过程之前从C#代码调用它们。到目前为止,我还没有看到这种类型的验证,因为它会增加很多开销,具体取决于它是仅为一个或两个过程实现还是在所有数据库调用中实现。
您可以编写SQL API,它将返回DB所有/选定的程序以及当前的架构定义。检查此查询。 sys.parameters表中还有其他有用的信息。
SELECT OBJECT_NAME(ssp.object_id) objectName
,ssp.name ParameterName
,sst.name ParameterDataType
,ssp.max_length
,ssp.precision
,ssp.scale
FROM sys.parameters ssp
JOIN sys.types sst
ON ssp.system_type_id=sst.system_type_id
WHERE OBJECT_NAME(ssp.object_id) = 'pr_test1'
样本结果将是这样的。
但请记住,如果您没有提供正确的频率或何时获取此信息,仍可能发生异步问题。您可以做的最好的事情就是在对象调用之前获取此信息。而且你知道这样做的开销是多少。
答案 1 :(得分:0)
与环境的交互,例如:DB,服务等是功能和集成测试的工作。这些测试很慢,而且它们的数量应该很少。
如果单元测试需要很长时间,那么它不是单元测试。 单元测试可以检查预期参数是否设置为SqlCommand并且调用了execute方法。应该嘲笑数据库上下文。
此类单元测试的更正是更新存储过程的人员的责任。或者应该有一些DB规范,单元测试应该与之同步。