2

可以说我有一个像下面这样的课程。

我不确定如何针对它编写单元/集成测试。它需要重构吗？

会不会只是添加一个 Add/Find 方法（它实际上会有），在测试中调用 Add，然后调用 Delete，然后是 Find？

public class Repository
{
    public void DeleteProduct(int id)
    {
        var connstring = ""; //Get from web.config
        using(SqlConnection conn = new SqlConnection(connstring))
        {
            conn.Open();
            SqlCommand command = new SqlCommand("DELETE FROM PRODUCTS WHERE ID = @ID")
            command.Paramaters.Add("@ID", id)
            command.ExecuteNonQuery();
        }
    }
}
4

3 回答 3

2

黄金法则是不要测试framewkrk 的代码。除非此方法没有自定义逻辑，否则无需测试。我认为您想要实现的是分离存储库以简化单元测试。最好的方法是为您的存储库创建接口并模拟它。如果您真的想创建一些集成测试，那么您必须创建一些测试数据库，您可以在其中进行核弹实验。

于 2013-03-11T14:27:41.967 回答
1

我的建议 - 为存储库编写集成测试（因为您使用的是数据访问框架），除非您在存储库中执行的不仅仅是 CRUD。

Add/Find are all individual Repository methods, and they need to be tested themselves.

I would recommend, use Setup to setup seed data, that you know you can act on. In this case, insert records into Products table.

Then Act: Call Repository.Deleteproduct(<product id created in setup>)

Assert that: Product created in setup is deleted (Query the database again to check).

If you are using an ORM, this test would also test your mappings for Product.

于 2013-03-11T14:28:44.947 回答
0

我从未为数据库调用添加单元测试。这绝对是一个集成测试。没有什么可观察到的供您检查。

我知道 Java 有一些适合 JUnit 的工具。IT 要求您编写模仿前后的 XML 文件，然后将表的内容与 XML 文件进行比较。我确信.Net 会有类似的东西。但是我不确定这是否值得。我发现这些测试非常脆弱并且提供的价值很小。

我建议采取务实的方法，不要为数据库对象编写测试。而是测试那些与您的数据库对象交互的对象。

于 2013-03-11T14:27:44.597 回答