blocks|key|2885256|text|简短的答案是，没有好的方法来测试使用PHPUnit在实际数据库上的并发读/写。对于这项工作，它根本不是合适的工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2885257|但是有几个方面的好的解决方案来测试这一点。首先，可以(也应该)编写代码来处理所有可能的问题。像PostgreSQL这样的数据库系统会在锁和事务问题上立即失败。为了优雅地处理它，我使用了类似如下的代码(伪代码，也用于回答another+question)：|offset|length|2885258|begin+transaction
while+not+successful+and+count+<+5
++++try+
++++++++execute+sql
++++++++commit
++++except
++++++++if+error+code+is+'40P01'+or+'55P03'
++++++++++++#+Deadlock+or+lock+not+available
++++++++++++sleep+a+random+time+(200+ms+to+1+sec)+*+number+of+retries
++++++++else+if+error+code+is+'40001'+or+'25P02'
++++++++++++#+"In+failed+sql+transaction"+or+serialized+transaction+failure
++++++++++++rollback
++++++++++++sleep+a+random+time+(200+ms+to+1+sec)+*+number+of+retries
++++++++++++begin+transaction
++++++++else+if+error+message+is+'There+is+no+active+transaction'
++++++++++++sleep+a+random+time+(200+ms+to+1+sec)+*+number+of+retries
++++++++++++begin+transaction
++++increment+count|code-block|syntax|javascript|2885259|然后创建两组测试:一组应该确认代码正确地处理了情况(即单元测试)。另一组测试是针对环境的(即集成/功能测试)。|2885260|单元测试|style|BOLD|2885261|我发现在连接到数据库的PHPUnit测试中很难重现这种情况，而且使用真正的数据库不适合进行真正的单元测试。相反，应该创建抛出各种数据库异常的PDO存根和单元测试。这证实了代码按预期工作，但是没有在任何真正的数据库上测试并发性。请记住，单元测试只是用来确认你的代码写得是否正确，而不是用来测试第三方软件。|2885262|$iterationCount+=+0;
$db->runInTransaction(function()+use+(&$iterationCount)+{
++++$iterationCount%2B%2B;
++++if+($iterationCount+===+1)+{
++++++++$exception+=+new+PDOExceptionStub('Deadlock');
++++++++$exception->setCode('40P01');
++++++++throw+$exception;
++++}
});

//+First+time+fails,+second+time+succeeds
$this->assertEquals(2,+$iterationCount,+'Expected+2+iterations+of+runInTransaction');|2885263|编写一套完整的测试，不连接到数据库，但确认逻辑。|2885264|集成测试|2885265|正如您已经发现的，PHPUnit根本不是执行负载测试的正确工具。它不适合任何比顺序单元和集成测试更复杂的测试。您可以同时运行多个PHPUnit实例，以增加数据库的负载。然而，我发现这超出了它的本意，而且它也不能帮助您监视数据库中的问题。因此，我认为没有办法绕过您希望避免的更高级别的测试。|2885266|但是，您的库可以在不运行完整应用程序的情况下进行测试。我会创建最简单的应用程序来测试它。它可以有一个或多个连接到数据库的CLI脚本。可以多次派生这些脚本，以将负载放到数据库上。或者使用该库创建一个简单的web页面，并使用许多负载测试应用程序中的任何一个来测试它。|2885267|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/42488679/handle-locks-in-redshift^0|0|31|G|0|0|0|0|0|4|0|2N|B|0|0|0|0|4|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@$D|1C|E|1D|1|1E]]|A|$]]|$1|F|3|G|5|H|7|1F|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1G|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1H|8|@$D|1I|E|1J|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1K|8|@$D|1L|E|1M|O|P]]|9|@]|A|$]]|$1|S|3|T|5|H|7|1N|8|@]|9|@]|A|$I|J]]|$1|U|3|V|5|6|7|1O|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1P|8|@$D|1Q|E|1R|O|P]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1S|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1T|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

The short answer is there's no good way to test concurrent reads/writes on an actual database with PHPUnit. It's simply not the right tool for that job.
But there are a few facets to a good solution for testing this. First the code can (and should) be written to handle every possible issue. A database system like PostgreSQL will fail immediately on locks and transaction issues. To handle it elegantly I use code that looks something like this (pseudo-code, also used to answer <a href="https://stackoverflow.com/questions/42488679/handle-locks-in-redshift">another question</a>):
<pre><code>begin transaction
while not successful and count &lt; 5
 try 
 execute sql
 commit
 except
 if error code is '40P01' or '55P03'
 # Deadlock or lock not available
 sleep a random time (200 ms to 1 sec) * number of retries
 else if error code is '40001' or '25P02'
 # &quot;In failed sql transaction&quot; or serialized transaction failure
 rollback
 sleep a random time (200 ms to 1 sec) * number of retries
 begin transaction
 else if error message is 'There is no active transaction'
 sleep a random time (200 ms to 1 sec) * number of retries
 begin transaction
 increment count
</code></pre>
Then create two sets of tests: one set should confirm the code is handling the situations correctly (i.e. unit tests). The other set of tests is for the environment (i.e. integration / functional tests).
Unit Tests
I find this to be a hard situation to reproduce in a PHPUnit test that connects to a database, and using a real database isn't appropriate for a true unit test. Instead, create PDO stubs and unit tests that throw every kind of database exception. This confirms the code is working as expected, but does not test concurrency on any real database. Remember, unit tests are only for confirming your code is written correctly, not for testing 3rd party software.
<pre><code>$iterationCount = 0;
$db-&gt;runInTransaction(function() use (&amp;$iterationCount) {
 $iterationCount++;
 if ($iterationCount === 1) {
 $exception = new PDOExceptionStub('Deadlock');
 $exception-&gt;setCode('40P01');
 throw $exception;
 }
});

// First time fails, second time succeeds
$this-&gt;assertEquals(2, $iterationCount, 'Expected 2 iterations of runInTransaction');
</code></pre>
Write a complete suite of tests that don't connect to the DB, but confirm logic.
Integration Tests
As you have found, PHPUnit is simply not the right tool to perform a load test. It's not appropriate for anything more complex than sequential unit and integration tests. You could run multiple instances of PHPUnit concurrently to put more load on the database. However I find this goes beyond what it was meant for, plus it doesn't help you monitor the database for issues. Therefore I see no way around the higher level tests you're looking to avoid.
But your library can be tested without running your complete application. I would create the simplest possible application just for testing it. It can have one or more CLI scripts that connect to a database. Those scripts can be spawned multiple times to put load on the database. Or make a simple web page with the library and use any of the many load testing applications out there to test it.

I recently encountered an issue on a live application.
I realized I had more and more concurrency exceptions and locks with a database.

Basically I start a transaction which requires a <code>SELECT</code> and an <code>INSERT</code> on the same table to commit.

But because the load is really heavy, each transactions locks the table, in most case it is so fast it doesn't cause any problems but there is a point where the locks start waiting more and more.

I was able to somewhat fix this problem by tweaking the queries.

Though, now, I'd like to write some tests with PHPUnit to validate my fix and avoid any regressions.

I was not able to find any materials on how to do this. 

Since PHP isn't multi threaded, I've no ideas how I could run concurrent queries in a single test to validate.

Basically, I would like to be able to run multiple calls in a single test to ensure everything is ok.

I know I could try to do some high level tests by directly querying the http server and load the whole application, but since my problem comes from a standalone library I'd rather like to test it against itself.

Any ideas?

How to unit test concurrent read/write with PHPUnit?

单元测试

集成测试

负载测试

PostgreSQL

数据库

服务器

我最近在一个实时应用程序上遇到了一个问题。我意识到数据库的并发异常和锁越来越多。基本上，我启动了一个事务，它需要同一个表上的一个SELECT和一个INSERT来提交。但是因为负载很重，每个事务都会锁定表，在大多数情况下，它是如此之快，以至于不会造成任何问题，但是有一个点，锁开始等待的时间越来越长。通过调整查询，我在一定...

问如何使用PHPUnit对并发读写进行单元测试？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用PHPUnit对并发读写进行单元测试？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用PHPUnit对并发读写进行单元测试？
EN