CiviCRM Community Forums (archive)

At the moment most api tests test that if the input is not an array the error message e.g

    function testGetParamsNotArrayContribution()
    {
        $params = 'string';                           
        $contribution =& civicrm_contribution_get($params);
        $this->assertEquals( $contribution['is_error'], 1 );
        $this->assertEquals( $contribution['error_message'], 'Input variable `params` is not an array' );
    }


This seems like a lot of duplicated code having it in every test and where there are missing test classes / cases it isn't tested.

It would make sense to have a test that runs through every api file & tests each create, get, delete function for this but that would break the structure.

Or alternatively, could each test call the same function which tests create, get, delete (or probably any function that doesn't start with _) for this. That would still miss those with no class but get those missing the specific test.

If both of those ideas break the ethos of testing we could at least define the error string in CiviUnitTestCase rather than in each test case?

Hi,

Nice one. Would make sense to extend later to verify that _delete _modify generates errors if it hasn't param['id'].

As for the signature, the more I think about it, the more it should be civicrm_api3_ or something not the same as the api v2 indeed.

X+

Better be too late that even more too late IMO.

Let's check on IRC what civicore think about it.

X+

OK - check

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

At the moment it fails on

1) api_v3_APIStandardsTest::testParamsNotArray
civicrm_api3_case_create does not return correct error when a non-array is submi
tted in line 92
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Input variable `params` is not an array
+Invalid or missing input parameters. Must provide an associative array.

Which is because 'civicrm_api3_verify_mandatory hasn't been added into the Case api as yet

Ideally ALL api functions that don't start with _ would have to meet the api standards (which might mean renaming some functions that are internal with the _)