blocks|key|1292955|text|我认为最好的做法是模拟所有对数据库的访问-只需在调用时返回一些预先确定的静态数据-你不需要测试数据库是如何工作的-你需要测试你的单元行为。你的单元测试与外部交互越少--它就越好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1292956|通过mocking，您将能够检查对数据库的调用是否有效，而无需真正调用它，所以我认为这是您需要的。|1292957|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think the best practice is really to Mock all access to database - just return some predetermined static data on call - you don't need to test how databases work - your need to test your unit behavior. Lesser your unit test interacts with outside - better it is.

With mocking your will be able to check that call to database is valid without really invoking it, so it's what you need i think.

blocks|key|1507583|text|你应该尝试分层你的代码，这样你就可以模拟你的函数的操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1507584|实际需要与数据库通信的层可以使用一个系统来设置数据并在事务中处理数据，您可以在测试结束时回滚该系统。|1507585|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You should try to layer your code so that you can mock the operation of your functions. 

The layer that does actually need to talk to the database could use a system of setting up the data and working with it within a transaction, which you would rollback at the end of the test.

blocks|key|1293124|text|我建议模拟数据访问级别。在这种情况下使用mock的好处包括:+1)单元测试将运行得更快。如果他们必须做连接到数据库、提取数据等全部工作，那么成本将变得昂贵。昂贵的测试=人们停止运行它们/开始对它们失去信心！2)您可以测试大量的场景，而不必经历设置合适的测试/静态数据的麻烦，在测试开始之前，您必须确保这些数据始终存在于数据库中。3)从等式中去掉外部数据库系统意味着您只测试您想要测试的.NET代码。没有外部依赖。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1293125|您可以使用一个执行纯数据库交互的数据访问层，然后对其进行模拟。或者，在.NET代码中使用模拟SqlCommands等。|1293126|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'd recommend mocking the data access level. The benefit of using mocks in this instance include:
1) unit tests will run quicker. If they have to do the full work of connecting to the db, extracting data etc. then the cost will become expensive. Expensive tests = people stop running them/start losing faith in them!
2) You can test a vast range of scenarios without having to go through the hassle of setting up suitable test/static data that you have to ensure is always in the DB before the tests start.
3) taking away the external db system from the equation means you are testing just the .NET code you want to test. No external dependency.

You could either have a data access layer that does pure db interaction, and then mock that. Or, use mock SqlCommands etc in your .NET code.

blocks|key|1293196|text|答案是嘲笑|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1293197|然而，我发现这样做的方法如下。|1293198|将DAL分成2层。底层只执行对数据库的原子读写操作--这些对象都实现了一组接口IReadFromDB和IWriteToDB。|1293199|然后，您可以在更高的DAL级别创建读写业务逻辑，而不是引用将对数据库进行读写的对象，而是引用接口并使用属性来替代功能。我倾向于在构造器中包含所需的函数对象，以便可以说“开箱即用”。|1293200|这将使得“交换”功能以及对业务逻辑进行单元测试变得轻而易举。|1293201|至于测试数据库读写...我还没有找到一种不涉及工作的方法。我通常对数据库的副本使用不同的连接字符串，然后编写单元测试的数据生成和清理代码，以使数据库的状态在前后保持不变。|1293202|是的，这很耗时...然而，它不会有疏远客户的风险。这取决于你的优先级。|1293203|还有人提到了性能测试。我不认为这是单元测试的一部分。我通常使用测试工具结合调试代码来做到这一点，原因很简单，因为小部件的性能通常是误导性的-当你移到大图上时，实际上是外壳问题的部件通常不是我经验中本地化测试会标记的部件。|1293204|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

The answer is mocking

However the way to do this I have found is as follows.

Separate the DAL into 2 layers. The bottom simply performs atomic read and writes to the databases - these objects all implement a set of interfaces IReadFromDB and IWriteToDB.

Then you can create your read and write business logic in a higher DAL level but rather than reference the objects that will read and write to the database reference the interfaces and use properties to be able to substitute functionality. I tend to include the desired functional objects in the constructors so that things work 'out of the box' so to speak.

This will make it a cinch to 'swap out' the functionality and so to unit test the business logic.

As for testing the DB read and writes ... I haven't found a way that doesn't involve work.
I usually use a different connection string to a copy of the database and then write data generation and cleanup code for unit tests to leave the state of the db the same as before and after.

Yes, its time consuming ... however it doesn't risk alienating a client. It depends on your priorities.

Someone else mentioned performance testing. I would not consider this to be part of a unit test. I usually do this with a test harness in combination with debug code simply because performance of small parts is often misleading - when you move to the big picture the parts that are actually casing problems are often not the parts that localised testing would flag in my experience.

blocks|key|1507833|text|我会对数据访问层进行抽象，然后对其进行模拟。使用mocking，您将能够增加测试的代码覆盖率。它还将防止通过对网络/文件系统/数据库进行昂贵的调用而发生“Test+Cancer”的想法，因为人们将停止运行它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1507834|您应该有一些调用数据库的测试，但它们应该受到尽可能多的限制。|1507835|entityMap|0|LINK|mutability|MUTABLE|url|http://www.martinfowler.com/bliki/TestCancer.html^0|25|B|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I would abstract the data access layer and then mock it. With mocking you will be able to increase the code coverage of your tests. It will also prevent the idea of '<a href="http://www.martinfowler.com/bliki/TestCancer.html" rel="nofollow noreferrer">Test Cancer</a>' that will happen by doing expensive calls to network/filesystem/database because people will stop running them.

You should have a few tests that call to the database but they should be limited as much as possible.

blocks|key|1293313|text|在我的工作中，我们使用Nunit和Typemock进行单元测试。事实上，我们不需要为测试更改代码，这是一个很大的优势。嘲笑DAL是一条可行的道路。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1293314|entityMap|0|LINK|mutability|MUTABLE|url|http://www.typemock.com/^0|H|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

In my work we use Nunit and <a href="http://www.typemock.com" rel="nofollow noreferrer">Typemock</a> for our Unit testing. The fact that we don't need to change our code for the tests is a big plus. Mocking the DAL is the way to go.

What is the best way to unit test heavily database dependant .NET middleware? E.g. a process which reads data from multiple databases, manipulates it, and then combines and writes it to other databases?

Should the databases be filled with static data which is somehow reset on each unit test run? Should the whole SQL Server access be somehow mocked? Is it not feasible to unit test such an application in the real world?

Unit Testing Database Driven .NET Applications

单元测试

性能测试

文件系统

SQL Server

中间件

数据库

对大量依赖于数据库的.NET中间件进行单元测试的最佳方法是什么？例如，从多个数据库读取数据，对其进行操作，然后将其合并并写入其他数据库的进程？是否应该用每次单元测试运行时以某种方式重置的静态数据填充数据库？是否应该以某种方式对整个SQL Server访问进行模拟？在现实世界中对这样的应用程序进行单元测试是不可行的吗？

问单元测试数据库驱动的.NET应用程序
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试数据库驱动的.NET应用程序EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单元测试数据库驱动的.NET应用程序
EN