Hi Platonides,
On Tue, Jul 03, 2012 at 12:40:35AM +0200, Platonides wrote:
On 01/07/12 13:49, Christian Aistleitner wrote:
But as I said, one would mock /above/ the SQL layer.
I was thinking on it. Some operations are easy, insert a field, select
a field, you can perform the joins in php.
Christian, thanks for the information about DatabaseBase for mocking, that
makes sense.
I don't know PHP at all, but I know something about how to do automated
tests. Besides manipulating tables directly, I've seen a couple of other
things in the unit tests that struck me as strange also:
* at
On 01/07/12 13:49, Christian Aistleitner wrote:
One might think so, yes.
But as I said, one would mock /above/ the SQL layer.
For typical database operations, SQL would not even get generated in
the first place!
Consider for example code containing
$db-insert( $param1, $param2, ... );
Hi Platonides,
On Sat, Jun 30, 2012 at 03:45:14PM +0200, Platonides wrote:
On 30/06/12 14:24, Christian Aistleitner wrote:
[ Mocking the database ]
[...]
One would have to abstract database access above the SQL
layer (separate methods for select, insert, ...) [...]
You still need
Hi Chris,
On Thu, Jun 28, 2012 at 08:25:05AM -0600, Chris McMahon wrote:
P.S.: On a related note ... one could think about mocking the database
as a whole for PHPUnit tests. Thereby, one would get rid of
unnecessary database coupling for unit testing, get better
control/detection of side
On 30/06/12 14:24, Christian Aistleitner wrote:
In our case, Object A is the object we want to test.
B is an implementation of DatabaseBase.
B' is a mock implementation of DatabaseBase.
C is the load balancer / wfGetDB(...) / ... whatever layer you choose.
Typically, mocking the database is
P.S.: On a related note ... one could think about mocking the database
as a whole for PHPUnit tests. Thereby, one would get rid of
unnecessary database coupling for unit testing, get better
control/detection of side effects, and really solve the database
performance problem for unit tests
Am 28/06/12 01:41, Christian Aistleitner schrieb:
Hi Daniel,
On Wed, Jun 27, 2012 at 09:59:19PM +0200, Daniel Kinzler wrote:
* MediaWikiTestCase will notice this group and use temporary tables instead
of
the wiki database's actual tables. The temporary tables are re-created for
every
Hi all
Phpunit tests that use the database should use @group Database. But that makes
them extremely slow. I'd like to elevate this problem. Here's the situation:
@group Database does two things, as far as I understand:
* MediaWikiTestCase will notice this group and use temporary tables instead
On 27/06/12 21:59, Daniel Kinzler wrote:
If we decide to do this, there should be some way to define and re-create the
initial contents of the read-only database. Perhaps a maintenance script that
other parts of the code (and extensions) can register with could do the trick.
What do you
Hi Daniel,
On Wed, Jun 27, 2012 at 09:59:19PM +0200, Daniel Kinzler wrote:
* MediaWikiTestCase will notice this group and use temporary tables instead of
the wiki database's actual tables. The temporary tables are re-created for
every
test. This protected the wiki from modifications through
11 matches
Mail list logo
