blocks|key|1562226|text|如果您想要对您的类进行单元测试，您应该模拟数据库访问。毕竟，您不希望在单元测试中测试数据库。这将是一次集成测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562227|将调用抽象出来，然后插入一个仅返回预期数据的mock。如果您的类除了执行查询之外并不能做更多的工作，那么测试它们可能就不值得了……|1562228|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 mock the database access if you want to unit test your classes. After all, you don't want to test the database in a unit test. That would be an integration test. 

Abstract the calls away and then insert a mock that just returns the expected data. If your classes don't do more than executing queries, it may not even be worth testing them, though...

blocks|key|1562290|text|我通常尝试在测试对象(和ORM，如果有的话)和测试db之间进行测试。我通过模拟数据访问调用来测试事物的对象端，而我通过测试对象与数据库的交互来测试事物的数据库端，在我的经验中，这通常是相当有限的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562291|我曾经对编写单元测试感到沮丧，直到我开始模拟数据访问部分，这样我就不必创建测试数据库或动态生成测试数据。通过模拟数据，您可以在运行时生成所有数据，并确保您的对象能够正确处理已知输入。|1562292|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 usually try to break up my tests between testing the objects (and ORM, if any) and testing the db. I test the object-side of things by mocking the data access calls whereas I test the db side of things by testing the object interactions with the db which is, in my experience, usually fairly limited.

I used to get frustrated with writing unit tests until I start mocking the data access portion so I didn't have to create a test db or generate test data on the fly. By mocking the data you can generate it all at run time and be sure that your objects work properly with known inputs.

blocks|key|1562369|text|我从未在PHP中这样做过，也从未使用过Python，但您想要做的是模拟对数据库的调用。要做到这一点，你可以实现一些IoC，无论是第三方工具还是你自己管理它，然后你可以实现一些模拟版本的数据库调用者，在那里你将控制虚假调用的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1562370|只需对接口进行编码，就可以执行简单形式的IoC。这需要在您的代码中进行某种面向对象，因此它可能不适用于您所做的事情(我说这是因为我所要做的就是您提到的PHP和Python)|1562371|希望这是有帮助的，如果没有别的，你现在有一些术语可供搜索。|1562372|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Inversion_of_Control^0|1L|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

I've never done this in PHP and I've never used Python, but what you want to do is mock out the calls to the database. To do that you can implement some <a href="http://en.wikipedia.org/wiki/Inversion_of_Control" rel="nofollow noreferrer">IoC</a> whether 3rd party tool or you manage it yourself, then you can implement some mock version of the database caller which is where you will control the outcome of that fake call.

A simple form of IoC can be performed just by coding to Interfaces. This requires some kind of object orientation going on in your code so it may not apply to what your doing (I say that since all I have to go on is your mention of PHP and Python)

Hope that's helpful, if nothing else you've got some terms to search on now.

blocks|key|1562403|text|我同意第一个后期数据库访问应该被剥离到一个实现接口的DAO层。然后，您可以针对DAO层的存根实现测试您的逻辑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562404|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I agree with the first post - database access should be stripped away into a DAO layer that implements an interface. Then, you can test your logic against a stub implementation of the DAO layer.

blocks|key|1777708|text|xUnit+Test+Patterns一书描述了一些处理命中数据库的单元测试代码的方法。我同意其他人的说法，你不想这样做，因为它很慢，但你必须在某个时候这样做，国际海事组织。模拟数据库连接以测试更高级别的东西是一个好主意，但请查看这本书，了解有关如何与实际数据库进行交互的建议。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1777709|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0131495054^0|0|J|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]]]]

The book <a href="https://rads.stackoverflow.com/amzn/click/com/0131495054" rel="noreferrer" rel="nofollow noreferrer">xUnit Test Patterns</a> describes some ways to handle unit-testing code that hits a database. I agree with the other people who are saying that you don't want to do this because it's slow, but you gotta do it sometime, IMO. Mocking out the db connection to test higher-level stuff is a good idea, but check out this book for suggestions about things you can do to interact with the actual database.

blocks|key|1777771|text|如果您的项目始终具有高内聚性和松散耦合，那么对数据库访问进行单元测试就足够容易了。通过这种方式，您可以只测试每个特定类所做的事情，而不必立即测试所有内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1777772|例如，如果您对用户界面类进行单元测试，那么您编写的测试应该只尝试验证UI内部的逻辑是否按预期工作，而不是验证该函数背后的业务逻辑或数据库操作。|1777773|如果您想要对实际的数据库访问进行单元测试，那么您实际上将得到更多的集成测试，因为您将依赖于网络堆栈和数据库服务器，但是您可以验证您的SQL代码是否执行了您要求它做的事情。|1777774|对我个人来说，单元测试隐藏的力量是，它迫使我以一种比没有它们更好的方式设计我的应用程序。这是因为它真的帮助我摆脱了“这个函数应该做所有事情”的心态。|1777775|对不起，我没有任何关于PHP/Python的特定代码示例，但是如果您想看.NET示例，我有一个post，它描述了我用来做同样测试的一种技术。|offset|length|1777776|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/12374/has-anyone-had-any-success-in-unit-testing-sql-stored-procedures#25204^0|0|0|0|0|1B|4|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@$J|Y|K|Z|1|10]]|A|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]]]

Unit testing your database access is easy enough if your project has high cohesion and loose coupling throughout. This way you can test only the things that each particular class does without having to test everything at once. 

For example, if you unit test your user interface class the tests you write should only try to verify the logic inside the UI worked as expected, not the business logic or database action behind that function. 

If you want to unit test the actual database access you will actually end up with more of an integration test, because you will be dependent on the network stack and your database server, but you can verify that your SQL code does what you asked it to do.

The hidden power of unit testing for me personally has been that it forces me to design my applications in a much better way than I might without them. This is because it really helped me break away from the "this function should do everything" mentality.

Sorry I don't have any specific code examples for PHP/Python, but if you want to see a .NET example I have a <a href="https://stackoverflow.com/questions/12374/has-anyone-had-any-success-in-unit-testing-sql-stored-procedures#25204">post</a> that describes a technique I used to do this very same testing.

blocks|key|1777853|text|对具有数据库访问权限的对象进行单元测试的最简单方法是使用事务作用域。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1777854|例如：|1777855|++++[Test]
++++[ExpectedException(typeof(NotFoundException))]
++++public+void+DeleteAttendee()+{

++++++++using(TransactionScope+scope+=+new+TransactionScope())+{
++++++++++++Attendee+anAttendee+=+Attendee.Get(3);
++++++++++++anAttendee.Delete();
++++++++++++anAttendee.Save();

++++++++++++//Try+reloading.+Instance+should+have+been+deleted.
++++++++++++Attendee+deletedAttendee+=+Attendee.Get(3);
++++++++}
++++}|code-block|syntax|javascript|1777856|这将恢复数据库的状态，基本上类似于事务回滚，因此您可以根据需要多次运行测试，而不会产生任何副作用。我们已经在大型项目中成功地使用了这种方法。我们的构建确实需要一点时间来运行(15分钟)，但对于拥有1800个单元测试来说，这并不可怕。此外，如果构建时间是一个问题，您可以将构建过程更改为具有多个构建，一个用于构建src，另一个随后启动以处理单元测试、代码分析、打包等……|1777857|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The easiest way to unit test an object with database access is using transaction scopes. 

For example:

<pre><code> [Test]
 [ExpectedException(typeof(NotFoundException))]
 public void DeleteAttendee() {

 using(TransactionScope scope = new TransactionScope()) {
 Attendee anAttendee = Attendee.Get(3);
 anAttendee.Delete();
 anAttendee.Save();

 //Try reloading. Instance should have been deleted.
 Attendee deletedAttendee = Attendee.Get(3);
 }
 }
</code></pre>

This will revert back the state of the database, basically like a transaction rollback so you can run the test as many times as you want without any sideeffects. We've used this approach successfully in large projects. Our build does take a little long to run (15 minutes), but it is not horrible for having 1800 unit tests. Also, if build time is a concern, you can change the build process to have multiple builds, one for building src, another that fires up afterwards that handles unit tests, code analysis, packaging, etc...

blocks|key|1562755|text|我建议模拟你对数据库的调用。模拟基本上是看起来像你试图调用方法的对象的对象，从某种意义上说，它们具有相同的属性、方法等可供调用者使用。但是，当一个特定的方法被调用时，它不会执行它们被编程执行的任何操作，而是完全跳过这一步，只返回一个结果。这个结果通常是由你提前定义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562756|为了将对象设置为模拟，您可能需要使用某种控制反转/依赖注入模式，如下面的伪代码所示：|1562757|class+Bar
{
++++private+FooDataProvider+_dataProvider;

++++public+instantiate(FooDataProvider+dataProvider)+{
++++++++_dataProvider+=+dataProvider;
++++}

++++public+getAllFoos()+{
++++++++//+instead+of+calling+Foo.GetAll()+here,+we+are+introducing+an+extra+layer+of+abstraction
++++++++return+_dataProvider.GetAllFoos();
++++}
}

class+FooDataProvider
{
++++public+Foo[]+GetAllFoos()+{
++++++++return+Foo.GetAll();
++++}
}|code-block|syntax|javascript|1562758|现在，在您的单元测试中，您将创建一个FooDataProvider模拟，它允许您在不必实际访问数据库的情况下调用方法GetAllFoos。|1562759|class+BarTests
{
++++public+TestGetAllFoos()+{
++++++++//+here+we+set+up+our+mock+FooDataProvider
++++++++mockRepository+=+MockingFramework.new()
++++++++mockFooDataProvider+=+mockRepository.CreateMockOfType(FooDataProvider);

++++++++//+create+a+new+array+of+Foo+objects
++++++++testFooArray+=+new+Foo[]+{Foo.new(),+Foo.new(),+Foo.new()}

++++++++//+the+next+statement+will+cause+testFooArray+to+be+returned+every+time+we+call+FooDAtaProvider.GetAllFoos,
++++++++//+instead+of+calling+to+the+database+and+returning+whatever+is+in+there
++++++++//+ExpectCallTo+and+Returns+are+methods+provided+by+our+imaginary+mocking+framework
++++++++ExpectCallTo(mockFooDataProvider.GetAllFoos).Returns(testFooArray)

++++++++//+now+begins+our+actual+unit+test
++++++++testBar+=+new+Bar(mockFooDataProvider)
++++++++baz+=+testBar.GetAllFoos()

++++++++//+baz+should+now+equal+the+testFooArray+object+we+created+earlier
++++++++Assert.AreEqual(3,+baz.length)
++++}
}|1562760|简单地说，这是一种常见的模仿场景。当然，您可能仍然希望对实际的数据库调用进行单元测试，为此，您需要访问数据库。|1562761|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I would suggest mocking out your calls to the database. Mocks are basically objects that look like the object you are trying to call a method on, in the sense that they have the same properties, methods, etc. available to caller. But instead of performing whatever action they are programmed to do when a particular method is called, it skips that altogether, and just returns a result. That result is typically defined by you ahead of time. 

In order to set up your objects for mocking, you probably need to use some sort of inversion of control/ dependency injection pattern, as in the following pseudo-code:

<pre class="lang-php prettyprint-override"><code>class Bar
{
 private FooDataProvider _dataProvider;

 public instantiate(FooDataProvider dataProvider) {
 _dataProvider = dataProvider;
 }

 public getAllFoos() {
 // instead of calling Foo.GetAll() here, we are introducing an extra layer of abstraction
 return _dataProvider.GetAllFoos();
 }
}

class FooDataProvider
{
 public Foo[] GetAllFoos() {
 return Foo.GetAll();
 }
}
</code></pre>

Now in your unit test, you create a mock of FooDataProvider, which allows you to call the method GetAllFoos without having to actually hit the database.

<pre class="lang-php prettyprint-override"><code>class BarTests
{
 public TestGetAllFoos() {
 // here we set up our mock FooDataProvider
 mockRepository = MockingFramework.new()
 mockFooDataProvider = mockRepository.CreateMockOfType(FooDataProvider);

 // create a new array of Foo objects
 testFooArray = new Foo[] {Foo.new(), Foo.new(), Foo.new()}

 // the next statement will cause testFooArray to be returned every time we call FooDAtaProvider.GetAllFoos,
 // instead of calling to the database and returning whatever is in there
 // ExpectCallTo and Returns are methods provided by our imaginary mocking framework
 ExpectCallTo(mockFooDataProvider.GetAllFoos).Returns(testFooArray)

 // now begins our actual unit test
 testBar = new Bar(mockFooDataProvider)
 baz = testBar.GetAllFoos()

 // baz should now equal the testFooArray object we created earlier
 Assert.AreEqual(3, baz.length)
 }
}
</code></pre>

A common mocking scenario, in a nutshell. Of course you will still probably want to unit test your actual database calls too, for which you will need to hit the database.

blocks|key|1562855|text|也许我可以让您体验一下我们开始对包含大量“业务逻辑”sql操作的中间层流程进行单元测试时的经验。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562856|我们首先创建了一个抽象层，允许我们“插入”任何合理的数据库连接(在我们的例子中，我们只支持一个ODBC类型的连接)。|1562857|一旦准备就绪，我们就可以在我们的代码中做一些类似这样的事情(我们在C%2B%2B中工作，但我相信你已经明白了)：|1562858|GetDatabase().ExecuteSQL(+"INSERT+INTO+foo+(+blah，blah+)“)|1562859|在正常运行时，GetDatabase()将返回一个对象，该对象通过ODBC直接将我们所有的sql+(包括查询)提供给数据库。|1562860|然后我们开始研究内存中的数据库--在很长一段时间内最好的似乎是SQLite。(http://www.sqlite.org/index.html)。它的设置和使用非常简单，并且允许我们子类化和覆盖GetDatabase()来将sql转发到内存中的数据库，该数据库是在每次执行测试时创建和销毁的。|offset|length|1562861|我们仍处于早期阶段，但到目前为止，它看起来很好，但是我们必须确保创建所需的任何表，并使用测试数据填充它们-然而，通过创建一组通用的助手函数，我们在一定程度上减少了工作量，这些函数可以为我们完成许多工作。|1562862|总体而言，它对我们的TDD过程有很大的帮助，因为由于sql/数据库的本质，进行看似非常无害的更改来修复某些错误可能会对系统的其他(难以检测的)区域产生相当奇怪的影响。|1562863|显然，我们的经验主要集中在C%2B%2B开发环境上，但是我相信您也可以在PHP/Python下获得类似的工作环境。|1562864|希望这能有所帮助。|1562865|entityMap|0|LINK|mutability|MUTABLE|url|http://www.sqlite.org/index.html^0|0|0|0|0|0|13|W|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|16|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|18|8|@]|9|@$L|19|M|1A|1|1B]]|A|$]]|$1|N|3|O|5|6|7|1C|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1D|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1E|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1F|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|12]]]]

I can perhaps give you a taste of our experience when we began looking at unit testing our middle-tier process that included a ton of "business logic" sql operations.

We first created an abstraction layer that allowed us to "slot in" any reasonable database connection (in our case, we simply supported a single ODBC-type connection).

Once this was in place, we were then able to do something like this in our code (we work in C++, but I'm sure you get the idea):

GetDatabase().ExecuteSQL( "INSERT INTO foo ( blah, blah )" )

At normal run time, GetDatabase() would return an object that fed all our sql (including queries), via ODBC directly to the database.

We then started looking at in-memory databases - the best by a long way seems to be SQLite. (<a href="http://www.sqlite.org/index.html" rel="noreferrer">http://www.sqlite.org/index.html</a>). It's remarkably simple to set up and use, and allowed us subclass and override GetDatabase() to forward sql to an in-memory database that was created and destroyed for every test performed.

We're still in the early stages of this, but it's looking good so far, however we do have to make sure we create any tables that are required and populate them with test data - however we've reduced the workload somewhat here by creating a generic set of helper functions that can do a lot of all this for us.

Overall, it has helped immensely with our TDD process, since making what seems like quite innocuous changes to fix certain bugs can have quite strange affects on other (difficult to detect) areas of your system - due to the very nature of sql/databases.

Obviously, our experiences have centred around a C++ development environment, however I'm sure you could perhaps get something similar working under PHP/Python.

Hope this helps.

blocks|key|1778087|text|为单元测试设置测试数据可能是一项挑战。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1778088|对于Java，如果您使用Spring+API进行单元测试，则可以在单元级别上控制事务。换句话说，您可以执行涉及数据库更新/插入/删除和回滚更改的单元测试。在执行结束时，您将数据库中的所有内容保留为开始执行之前的状态。对我来说，它已经是最好的了。|1778089|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|$]]

Setting up test data for unit tests can be a challenge.

When it comes to Java, if you use Spring APIs for unit testing, you can control the transactions on a unit level. In other words, you can execute unit tests which involves database updates/inserts/deletes and rollback the changes. At the end of the execution you leave everything in the database as it was before you started the execution. To me, it is as good as it can get.

I've heard that unit testing is "totally awesome", "really cool" and "all manner of good things" but 70% or more of my files involve database access (some read and some write) and I'm not sure how to write a unit test for these files.

I'm using PHP and Python but I think it's a question that applies to most/all languages that use database access.

How to unit test an object with database queries

单元测试

集成测试

数据库

服务器

SQLite

Python

Java

我听说单元测试“非常棒”，“真的很酷”，“各种各样的好东西”，但我的文件中有70%或更多涉及数据库访问(一些是读的，一些是写的)，我不确定如何为这些文件编写单元测试。我正在使用PHP和Python，但我认为这是一个适用于大多数/所有使用数据库访问的语言的问题。

问如何使用数据库查询对对象进行单元测试
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用数据库查询对对象进行单元测试EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用数据库查询对对象进行单元测试
EN