您如何对业务应用程序进行单元测试? [英] How do you unit test business applications?

问题描述

人们如何对他们的业务应用程序进行单元测试?我看过很多带有简单测试"示例的单元测试示例.前任.一个计算器.人们如何对数据密集型应用程序进行单元测试?你如何把你的样本数据放在一起?在很多情况下，一个测试的数据对于另一个测试可能根本不起作用，这使得只有一个测试数据库很困难?

How are people unit testing their business applications? I've seen a lot of examples of unit testing with "simple to test" examples. Ex. a calculator. How are people unit testing data-heavy applications? How are you putting together your sample data? In many cases, data for one test may not work at all for another test which makes it hard to just have one test database?

测试代码的数据访问部分相当简单.它正在测试所有适用于似乎难以测试的数据的方法.例如，想象一个发布过程，其中有大量数据访问来确定发布的内容、调整数字等.有许多中间步骤发生(并且需要测试)以及随后的测试，以确保发布是成功的.其中一些步骤实际上可能是存储过程.

Testing the data access portion of the code is fairly straightforward. It's testing out all the methods that work against the data that seem to be hard to test. For example, imagine a posting process where there is heavy data access to determine what is posted, numbers are adjusted, etc. There are a number of interim steps that occur (and need to be tested) along with tests afterwards that ensure the posting was successful. Some of those steps may actually be stored procedures.

过去我曾尝试将测试数据插入测试数据库，然后运行测试，但老实说，编写这种代码非常痛苦(而且容易出错).我还尝试过预先构建一个测试数据库并回滚更改.这工作正常，但在许多地方你也不能轻易做到这一点(很多人会说这是集成测试；所以，我仍然需要能够以某种方式测试它).

In the past I've tried inserting the test data in a test database, then running the test, but honestly it's pretty painful to write this kind of code (and error prone). I've also tried just building a test database up front and rolling back the changes. That works OK but in a number of places you can't easily do this either (and many people would say that's integration testing; so be it, I still need to be able to test this somehow).

如果答案是没有一种很好的方法来处理这个问题，而且目前它有点糟糕，那么了解一下也会很有用.

If the answer is that there isn't a nice way of handling this and it currently just sort of sucks, that would be useful to know as well.

感谢任何想法、想法、建议或提示.

Any thoughts, ideas, suggestions, or tips are appreciated.

推荐答案

当我尝试使用回滚解决方案来处理这些集成测试时，我必须附上@Phil Bennett 的评论.

I have to second the comment by @Phil Bennett as I try to approach these integration tests with a rollback solution.

我有一篇关于集成测试数据访问层的非常详细的帖子 这里

I have a very detailed post about integration testing your data access layer here

我不仅展示了示例数据访问类、基类和示例 DB 事务夹具类，而且还展示了带有示例数据的完整 CRUD 集成测试.使用这种方法，您不需要多个测试数据库，因为您可以控制每个测试的数据，并且在测试完成后，所有事务都会回滚，因此您的数据库是干净的.

I show not only the sample data access class, base class, and sample DB transaction fixture class, but a full CRUD integration test w/ sample data shown. With this approach you don't need multiple test databases as you can control the data going in with each test and after the test is complete the transactions are all rolledback so your DB is clean.

关于在您的应用程序中对业务逻辑进行单元测试，我还附上@Phil 和@Mark 的评论，因为如果您模拟出您的业务对象具有的所有依赖项，那么一次一个实体测试您的应用程序逻辑就变得非常简单时间;)

About unit testing business logic inside your app, I would also second the comments by @Phil and @Mark because if you mock out all the dependencies your business object has, it becomes very simple to test your application logic one entity at a time ;)

那么您是否正在寻找一个巨大的集成测试来验证从逻辑预数据库/存储过程运行到逻辑的所有内容，并最终在返回途中进行验证?如果是这样，您可以将其分解为 2 个步骤:

So are you looking for one huge integration test that will verify everything from logic pre-data base / stored procedure run w/ logic and finally a verification on the way back? If so you could break this out into 2 steps:

• 1 - 单元测试数据被推送之前发生的逻辑进入您的数据访问代码.为了例如，如果你有一些代码计算一些数字基于一些属性——写一个测试只检查逻辑是否为这 1 个函数执行您的要求它要做.模拟任何依赖在数据访问类上，这样你就可以在这个测试中忽略它单独的应用程序逻辑.

• 1 - Unit test the logic that happens before the data is pushed into your data access code. For example, if you have some code that calculates some numbers based on some properties -- write a test that only checks to see if the logic for this 1 function does what you asked it to do. Mock out any dependancy on the data access class so you can ignore it for this test of the application logic alone.

2 - 集成测试一旦你采取你的被操纵的数据(从以前的我们单元测试的方法)并调用适当的存储过程.做这里面有一个数据特定的测试类，以便您可以在它之后回滚完全的.在您存储后程序已经运行，做一个查询针对数据库获取您的现在我们已经做了一些反对针对数据的逻辑并验证它具有您期望的值(后存储过程逻辑/etc )

2 - Integration test the logic that happens once you take your manipulated data (from the previous method we unit tested) and call the appropriate stored procedure. Do this inside a data specific testing class so you can rollback after it's completed. After your stored procedure has run, do a query against the database to get your object now that we have done some logic against the data and verify it has the values you expected (post-stored procedure logic /etc )

如果您需要数据库中的条目来运行存储过程，只需在运行包含您的逻辑的 sproc 之前插入该数据.例如，如果您有一个需要测试的产品，它可能需要插入供应商和类别条目，因此在插入产品之前，请为供应商和类别快速而脏地插入，以便您的产品插入按计划工作.

If you need an entry in your database for the stored procedure to run, simply insert that data before you run the sproc that has your logic inside it. For example, if you have a product that you need to test, it might require a supplier and category entry to insert so before you insert your product do a quick and dirty insert for a supplier and category so your product insert works as planned.

这篇关于您如何对业务应用程序进行单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！