单元测试 - 数据库数据 [英] Unit testing - database data

问题描述

我尝试为某些具有存储过程的方法创建单元测试.以下是我的问题.

I tried creating unit tests for some methods that has stored procedures. Below are the questions i have.

• 如何对使用大量存储过程的项目进行单元测试从数据库中获取数据进行验证?

• How to unit test a project that uses lot of stored procedures to get the data from database for validations?

• 如果我必须从我的单元测试中调用这些方法，我实际上是不进行数据库调用...值得吗?

• If i have to call those methods from my unit test, i am actually making n no of database calls...Is it worth it?

如果我必须使用模拟数据，如何从本地数据库?

If i have to use the mock data, how to get the copy of the data from database locally?

如何模拟存储过程调用以使用模拟数据?

How to mimic the stored procedure calls to use the mock data?

推荐答案

您正在查看集成测试，而不是单元测试.集成测试依赖于外部系统(日期时间、数据库、文件系统、网络服务等)，而单元测试的范围仅限于一个单元(一个或多个类中的一个或多个方法).

You're looking at integration tests, not unit tests. Integration tests have a dependency from an external system (datetime, database, filesystem, networkservice, etc) while unit tests their scope is confined to one unit (one or more methods in one or more classes).

这里首先要意识到的是，为了进行集成测试，您将依赖于外部系统.您永远不想针对生产环境进行测试，并且希望保持对测试数据的控制.

The first thing to realize here is that in order to do an integration test, you will be relying on an external system. You never want to test against your production environment and you want to maintain control over the test data.

因此，您应该创建一个与现有数据库完全相同的数据库，但要去除所有数据并使用模拟数据.这可确保您的测试在整个更改过程中保持一致，从而可以信赖.
您还应该记住让您的测试数据库在功能上与您的实时数据库等效，以避免落后和过时的测试.

For this reason you should create a database that is exactly the same as your existing one but is stripped of all data and uses mock data instead. This makes sure that your tests will stay consistent throughout changes and thus can be relied upon.
You should also remember to keep your test database functionally equivalent to your live database to avoid falling behind and having outdated tests.

这里的关键是:抽象您的数据源层.如果您将所有数据库调用放在一个接口之后，您可以简单地模拟/存根该接口并从那里提供测试数据.

What's key here is this: abstract your data source layer. If you put all your database calls behind an interface, you can simply mock/stub this interface and provide test data from there.

您的工作单元应该切中要害，并测试该方法应该做的一件事(单一职责原则).
如果您的方法的目标是操作数据库中的数据，那么您可以模拟数据源并对操作进行单元测试.
如果您的方法的目标是调用数据库中的存储过程，那么您可以使用集成测试来提供过程输入并针对其输出进行断言.

Your unit of work should be to the point and test the one thing the method is supposed to do (Single Responsibility Principle).
If the objective of your method is to manipulate data from the database then you mock your data source and you unit test your manipulation.
If the objective of your method is to call a stored procedure in your database, then you use your integration test to feed the procedure input and assert against its output.

此原则的一个简单示例:

A simple example of this principle in action:

interface DataSource {
    List<String> GetData();
}

class Manipulator {
    private DataSource _source;

    public Manipulator() { }

    public Manipulator(DataSource d) { _source = d; }

    public void ManipulateData() {
        var data = _source.GetData();

        // Do something with the data
    }
}

此示例利用构造函数注入(查看依赖注入和 IoC 容器的概念！).

This sample utilizes constructor injection (look into the concepts of dependency injection and IoC containers!).

现在回答你的问题:

如果我必须从我的单元测试中调用这些方法，我实际上没有进行数据库调用...值得吗?

If i have to call those methods from my unit test, i am actually making n no of database calls...Is it worth it?

是的，否则您就没有集成测试.由于您有一个单独的测试数据库，因此不会干扰您的生产环境.

Yes, otherwise you don't have an integration test. Since you have a separate test database this will not interfere with your production environment.

如果我必须使用模拟数据，如何从本地的数据库中获取数据的副本?

If i have to use the mock data, how to get the copy of the data from database locally?

老实说，我不太确定你在这里问的是什么，但我认为它已经通过测试数据库的想法解决了.

I'm not quite sure what you're asking here to be honest, but I think it is resolved with the idea of a testing database.

如何模拟存储过程调用以使用模拟数据?

How to mimic the stored procedure calls to use the mock data?

你没有.您可以通过使用测试数据调用它们并根据您的期望断言结果来使用实际的存储过程.如果它们有效，那么一切就结束了，如果它们没有返回正确的结果，那么您就知道出了问题.

You don't. You use the actual stored procedures by calling them with your test data and asserting the result on what you expect. If they work then that's the end of it, if they don't return the correct result then you know something went wrong.

这篇关于单元测试 - 数据库数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！