Code: Select all
$array = array();
while($res->fetchInto($row, DB_FETCHMODE_ASSOC)) {
$array[$row['id']] = $row;
}Moderator: General Moderators
Code: Select all
$array = array();
while($res->fetchInto($row, DB_FETCHMODE_ASSOC)) {
$array[$row['id']] = $row;
}Code: Select all
$this->obj->db =& new MockDB_mysql($this);
$result_email =& new MockDB_result_email($this);
$result_ftp =& new MockDB_result_ftp($this);
$result_email->setReturnValue('fetchRow', false);
$result_email->setReturnValueAt(0, 'fetchRow',
array(
'id' => 4
,'address' => 'arcezy@gmail.com'
,'last_md5' => '072734bca324930cf0c2e48710425814'
));
$result_ftp->setReturnValue('fetchRow', false);
$result_ftp->setReturnValueAt(0, 'fetchRow',
array(
'id' => 2
,'server' => 'www.thewritingpot.com'
,'username' => 'backup'
,'password' => 'pass'
,'max_copies' => 'max_copies'
,'last_md5' => '072734bca324930cf0c2e48710425814'
));
$this->obj->db->setReturnValue('query', &$result_email, array(' SELECT `id`, `interval`, `last_md5` FROM `backup_email` WHERE ((NOW() - `interval`) >
`last_update`) '));
$this->obj->db->setReturnValue('query', &$result_ftp, array(' SELECT `id`, `interval`, `last_md5` FROM `backup_ftp` WHERE ((NOW() - `interval`) >
`last_update`) '));
$this->obj->getOperations();
//var_dump($this->obj->list_backups);
$this->assertEqual($this->obj->list_backups['backup_email'][4]['id'],4);
$this->assertEqual($this->obj->list_backups['backup_email'][4]['address'],'arcezy@gmail.com');Code: Select all
$this->obj->db->setReturnValue(...)Code: Select all
$db =& new MockDB_mysql($this);
$db->setReturnValue(...)
$db->setReturnValue(...)Code: Select all
$this->assertEqual($this->obj->list_backups['backup_email'][4]['id'],4);Ah... I think I understand. So it's a good idea not to use $this-> variables as things you stick variables in for easy access from functions? Edit No, I was mistaken, it's not a good idea to directly set object properties, there should always be a method above it.McGruff wrote:Setting object properties without named setters is cheating a bit. An object should have a well-defined interface.
For example you could pass the db object in to the primary class (ie the one being tested). Or, if you don't want the db object exposed in the design like that, you can use a factory method and partially mock in the test (the procedure is explained in the SimpleTest docs - but do ask if you'd like me to explain).
That makes sense. I suppose it's cleaner.McGruff wrote:Either way, rather than setting expectations for the mock db objectlike this:..just do this:Code: Select all
$this->obj->db->setReturnValue(...)..then pass it in or set as a return ref for the partially mocked method.Code: Select all
$db =& new MockDB_mysql($this); $db->setReturnValue(...) $db->setReturnValue(...)
Hmm... I'll incorporate those too.You probably ought to set some expectOnce/expectCallCount expectations as well (don't forget to tally up: $mock_object->tally() ).
Hmm... I think I need to post more code. Originally, getOperations cycled through an array of table names and performed a specific query on each of them. I suppose, then, that getOperations should be simply the cycling through the array, and then an alternate function/class handles the sql.Assertions like this;..aren't good because you're peeking under the bonnet. Is there another way to test if the getOperations call did what it was supposed to do? if all it's doing is teeing up the class I'd be tempted to do that in the constructor - maybe you can test another method of the primary class which actually does something? (I might not have grasped what you're doing exactly).Code: Select all
$this->assertEqual($this->obj->list_backups['backup_email'][4]['id'],4);
I'm not exactly sure what mechanism I should use (this is a pretty small project that's meant to be deployed only on one machine but maybe be deployed on a wider scale and I want to be flexible but I also want to get it finished.) The reason why I turned to unit testing was that I was throwing variables around until the properties table was a huge mess and I couldn't figure out where I stored any particular bit of information. I'm not even sure if I should be unit testing this sort of thing...We could even go as far as to mock every method except one we actually want to test.
This last situation is all rather hypothetical, as I haven't tried it. I am open to the possibility, but a little worried that forcing object granularity may be better for the code quality. I personally use partial mocks as a way of overriding creation or for occasional testing of the TemplateMethod pattern.
It's all going to come down to the coding standards of your project to decide which mechanism you use.
Code: Select all
$iterator = &new MockResultSet();
$iterator->setReturnValueAt(0, 'next', array(...));
$iterator->setReturnValueAt(1, 'next', array(...));
$connection = &new MockConnection();
$connection->setReturnReference('query', $iterator);