CiviCRM Community Forums (archive)

I'm just wondering if anyone has already tackled this? What I want to do is test whether an outbound email generated on an activity save contains what it's supposed to. It needs to be a webtest, because the email is only generated from the form.

If nobody's already done this, then some options I can think of:

- Have it set CIVICRM_MAIL_LOG, then parse the output of the log file.

- In this particular case I'm mostly interested in an attachment, so figure out how to have the unit test implement one of the civi hooks, and then check the attachments. I can see a CRM_Utils_Hook_UnitTests, but I'm not sure how to use it since it seems like a stub? Is this part of http://forum.civicrm.org/index.php/topic,26358.msg111755.html#msg111755 ? Or is now the standard way to call a hook from a core test to write an extension to go along with the core test?

Far less clever approach than Tim's - but I did add unit tests on the Contribution api & Base IPN based

http://svn.civicrm.org/civicrm/trunk/tests/phpunit/api/v3/ContributionTest.php

- look at the sendMail one (which sends out a contribution receipt)

So are you suggesting something more like this? (Note: I've slightly modified the naming convention to avoid accidental conflicts with test functions.)

<?php
class CRM_HookNamingConventionTest {
  function setUp() {
    CRM_Utils_Hook_UnitTest::setUp($this);
  }
  function testFooBar() {
    $this->hookState = 0;
    CRM_Contact_BAO_Contact::create(...); // create new contact
    CRM_Contact_BAO_Contact::create(...); // update contact
    $this->assertEquals(4, $this->hookState);
  }
  function hookFooBar_civicrm_pre($op, $objectName, $id, &$params) {
    switch (++$this->hookState) {
      case 1:
        $this->assertEquals('create', $op);
        $this->assertEquals('Individual', $objectName);
        break;
      case 3:
        $this->assertEquals('edit', $op);
        $this->assertEquals('Individual', $objectName);
        break;
      default:
        $this->fail("Bad call");
    }
  }
  function hookFooBar_civicrm_post($op, $objectName, $id, &$params) {
    switch (++$this->hookState) {
      case 2:
        $this->assertEquals('create', $op);
        $this->assertEquals('Individual', $objectName);
        break;
      case 4:
        $this->assertEquals('edit', $op);
        $this->assertEquals('Individual', $objectName);
        break;
      default:
        $this->fail("Bad call");
    }
  }
}

Note that it takes some care to get the assertions right -- it's easy to accidentally write a test which says "If hook X is called, then check it's parameters with logic Y" -- but the hook might never run or might run too many times. It's harder to say "Hook X is called once with parameter A, then hook Y is called once with parameter B, and then hook Y is called again with parameter C". I think the 'mock object' approach deals with this better, although I've had some trouble finding a tutorial on PHPUnit that covers all the right material. I've tried to piece together a better example. The key thing to note is that it affirmatively ensures that the hooks are run the correct number of times.

<?php
class CRM_MockHookTest {
  function setUp() {
    CRM_Utils_Hook_UnitTest::setUp($this);
  }
  function testFooBar() {
    $hook = $this->getMock('stdClass', array('pre', 'post'));
    CRM_Utils_Hook_UnitTest::setMock($hook);

    $hook->expects($this->at(1))
      ->method('pre')
      ->with('create', 'Individual', $this->anything(), $this->isType('object'));
    $hook->expects($this->at(2))
      ->method('post')
      ->with('create', 'Individual', $this->isType('int'), $this->isType('object'));
    CRM_Contact_BAO_Contact::create(...); // create new contact

    $hook->expects($this->at(3))
      ->method('pre')
      ->with('edit', 'Individual', $this->isType('int'), $this->isType('object'));
    $hook->expects($this->at(4))
      ->method('post')
      ->with('edit', 'Individual', $this->isType('int'), $this->isType('object'));
    CRM_Contact_BAO_Contact::create(...); // update contact
  }
}


Yeah, doing separate callbacks feels more fluid to me, but if one does want to do a separate named function, then they could still do it with setHook like:

<?php
class CRM_SeparateHookFunctionTest {
  function testFooBar() {
    CRM_Utils_Hook_Unit::setHook('pre', array($this, 'hookFooBar_civicrm_pre'));
  }
  function hookFooBar_civicrm_pre($op, $objectName, $id, &$params) {
    ..
  }
}

Agree that 99% of the time you want to clear the hook at the end of the test. I think we would do this automatically by updating CiviUnitTestCase::setUp() and CiviUnitTestCase::tearDown() to call CRM_Utils_Hook_UnitTests::reset().

Just a followup on using CIVICRM_MAIL_LOG - it doesn't seem to get recognized when run under WebTests, but I don't know why so will look closer at that. I added tests/phpunit/CiviTest/CiviMailService.php as its own class since the intention was so that it could be used from both WebTest and non-WebTest. IcalTest.php in tests/phpunit/WebTest/Activity is where I was going with it (the test currently fails).

In conversation with Lobo, there are actually two separate php instances during a webtest - the testing framework's and the instance running on your actual test site.

The current plan is to have a UI setting to store it in the db to override CIVICRM_MAIL_LOG - ticket is at http://issues.civicrm.org/jira/browse/CRM-11190

Agree that overriding CRM_Utils_Mail in an OOP sense would not help. Adding a config setting (and updating CRM_Core_Config::getMailer() to respect it) makes sense. (This will effectively change the behavior of CRM_Utils_Mail as well as the BAOs in CRM_Mailing.)

FWIW, the web-test process may be able to access the DB without going through a web request. (At least, there are several helpers like CiviSeleniumTestCase::assertDBState.) That may be easier than writing a new web-page.

But if you want to do a web UI, that's cool -- I think there are other use-cases for that, too. For example, on staging sites (where developers and non-developers work with pre-release system), the "spool-to-disk" works OK for developers but not for other testers. There are also times when admins want to see an exact replica of a message that was sent out. (I've esp seen this on smaller projects that don't have a rigorous staging/production process.) (For the second use-case, the configuration setting for "Logging-to-DB" would need to be separate from the configuration setting for "outBound_option" so that admin could choose any combination of logging/delivering.)

Thanks yeah that function was what I used when I first started testing it. I was going to move them into the CiviMailService - I will probably update those contribution tests to use whatever the new thing I end up with as a way to see if it also works for non-webtests.