为什么不在单元测试中打数据库? [英] Why not hit the database inside unit tests?

问题描述

我在博客中读到过，在单元测试运行时不应命中数据库.我理解这个理论，但是说我有复杂的存储过程，它们是业务域操作的一部分.我想为与业务操作相关的代码编写一组单元测试，但是如果我模拟数据库，我会感觉我没有真正"测试属于操作的所有部分.例如，有人可能在其中一个数据库代码中创建了一个错误，而测试仍然可以正常运行.

I've read in blogs that the database should not be hit when the unit tests run. I understand the theory, however say i have complex store procedures that are part of a business domain operation. I want to write a set of unit tests for the code related to the business operation, however if i mock the database i have the feeling that im not "really" testing all the parts that are part of the operation. For example someone could create a bug in one of the database code and the tests will still be running ok.

我想知道这个关于单元测试的指南在实践中是否有用.我已经看到了集成测试"的概念，但是我不确定使用什么工具来进行集成测试.例如 ¿ 可以使用 Nunit 之类的测试框架创建集成测试吗?

I would like to know if this guideline about unit tests is good in practice. I've seen the concept of "integration tests" however im not sure about what tools to use to do integration tests. For example ¿Is it ok to create an integration test using a test framework like Nunit?

谢谢

雨果

推荐答案

您只是处于语义灰色区域.

You are simply in a semantic grey area.

• 系统测试涵盖了端到端的整个系统.
• 单元测试可用于描述端到端周期的子部分.

在这种情况下，您的应用程序代码的单元测试将/可能不会命中数据库，但您将/可能会有涵盖数据库存储过程的单元测试...

In that case your unit tests of your application code would/might not hit the database, but you would/might have unit tests that covered your database stored procedures...

基本上将您的应用程序划分为沿着有意义的分区进行测试的内容.如果您选择了错误的分区线，您最终会遇到模拟对象和测试脚手架等大代码维护问题...

Basically divide your application into things to be tested along partitions that make sense. If you choose the wrong partition line you end up with a big code maintenance problem with mock objects and test scaffolding and stuff...

Web 应用程序的常见方法是编写一系列单元测试来测试数据访问层...

A common way with web apps is to write a series of unit tests that test the data access layer...

然后编写一系列单元测试，测试应用层(包括数据层)...

Then write a series of unit tests that test the application layer (including the data layer) ...

最后编写一些基于浏览器的系统测试...

And finally write some browser-based system tests...

诀窍是仅通过 API 将信息放入和取出中间集(应用层)，而不是钻入数据库以查看某些内容是否有效.这样一来，即使更改数据架构，您的测试也不会中断.

The trick is to only put information in and out of the middle set - the application layer - through the API and not burrow into the database to see if something worked. That way your tests won't break if you change the data schema.

但有时(正如我在撰写本文时实际上所做的那样)您必须查看数据库以制作有意义且强大的测试套件(我正在测试服务器 - 服务器传输协议).

But sometimes (as I actually currently doing as I write this) you HAVE to look into the database to make a meaningful and robust test suite (I am testing server-server transfer protocols).

专注于为您的应用程序获得最大代码覆盖率和稳定性的方式，同时编写最少的测试脚手架，并避免测试套件的脆弱性.

Focus on the way that gets maximum code coverage and stability for your application, whilst writing the least amount of testing scaffolding, and avoiding brittleness in your test suite.

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