mirror/PHPMailer
0
0
Fork 0
mirror of https://github.com/PHPMailer/PHPMailer.git synced 2024-09-20 10:02:14 +02:00
Code
ecfef2e99c
PHPMailer/test/SendTestCase.php

127 lines
4.2 KiB
PHP
Raw Normal View History

TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
<?php
/**
* PHPMailer - Base test class.
* PHP version 5.5.
*
* @author Marcus Bointon <phpmailer@synchromedia.co.uk>
* @author Andy Prevost
* @copyright 2012 - 2020 Marcus Bointon
* @copyright 2004 - 2009 Andy Prevost
* @license http://www.gnu.org/copyleft/lesser.html GNU Lesser General Public License
*/
namespace PHPMailer\Test;
SendTestCase: error out when the testbootstrap file cannot be found The `PHPMailerTest` class contained a `testBootstrap()` method to verify that the `testbootstrap.php` file exists as the first test in the class. As the order in which tests are run is not predefined, this is not reliable. Additionally, the check for the `testbootstrap.php` file is checking a pre-requisite for tests using the `PHPMailer::send()` method, so it would be better to verify via a condition in the `set_up()`. Now, using such a condition, there is choice: the test can either be marked as "skipped" when the `testbootstrap.php` file can not be found, or be marked as an "error". As the tests _should_ run, skipping them would hide an error in the dev-user test setup, so showing these tests as errors seems more appropriate. To that end, the `testBootstrap()` method has been removed and a check for the `testbootstrap.php` file has been added to the `SendTestCase::set_up()` which will now throw an appropriate `Exception` when the file is not found. Oops... also removes a stray `parent::set_up()` at the start of the local `set_up()` which should have been removed in 218fd13c8867ac7342dcafc3ccdeee57eb8e5da8
2021-07-03 05:44:52 +02:00
use Exception;
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
/**
* PHPMailer - Test class for tests which need the `PHPMailer::send()` method to be called.
*/
abstract class SendTestCase extends PreSendTestCase
{
SendTestCase: implement use of the `$propertyChanges` property The `SendTestCase` gets the values of the properties to be set from the `testbootstrap.php` file. This introduces a `private` property to map the field names used in `$_REQUEST` to the properties in the `PHPMailer` class and adds logic to the overloaded `set_up()` method to fill the `$propertyChanges` TestCase property. The actual setting of the properties in the `PHPMailer` instance is deferred to the underlying `TestCase` parent class. Includes adding support for presetting the `bcc` value for feature completeness. Overloading and/or adding to the `$propertyChanges` array from concrete test cases is, of course, supported, so if individual tests need additional presetting of properties, the same logic as mentioned in the previous commit can be used.
2021-07-03 05:14:40 +02:00
/**
* Translation map for supported $REQUEST keys to the property name in the PHPMailer class.
*
* @var array
*/
private $requestKeys = [
'mail_from' => 'From',
'mail_host' => 'Host',
'mail_port' => 'Port',
'mail_useauth' => 'SMTPAuth',
'mail_username' => 'Username',
'mail_userpass' => 'Password',
'mail_to' => 'to',
'mail_cc' => 'cc',
'mail_bcc' => 'bcc',
];
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
/**
* Run before each test is started.
*/
protected function set_up()
{
SendTestCase: error out when the testbootstrap file cannot be found The `PHPMailerTest` class contained a `testBootstrap()` method to verify that the `testbootstrap.php` file exists as the first test in the class. As the order in which tests are run is not predefined, this is not reliable. Additionally, the check for the `testbootstrap.php` file is checking a pre-requisite for tests using the `PHPMailer::send()` method, so it would be better to verify via a condition in the `set_up()`. Now, using such a condition, there is choice: the test can either be marked as "skipped" when the `testbootstrap.php` file can not be found, or be marked as an "error". As the tests _should_ run, skipping them would hide an error in the dev-user test setup, so showing these tests as errors seems more appropriate. To that end, the `testBootstrap()` method has been removed and a check for the `testbootstrap.php` file has been added to the `SendTestCase::set_up()` which will now throw an appropriate `Exception` when the file is not found. Oops... also removes a stray `parent::set_up()` at the start of the local `set_up()` which should have been removed in 218fd13c8867ac7342dcafc3ccdeee57eb8e5da8
2021-07-03 05:44:52 +02:00
/*
* Make sure the testbootstrap.php file is available.
* Pretty much everything will fail due to unset recipient if this is not done, so error
* the tests out before they run if the file does not exist.
*/
if (file_exists(\PHPMAILER_INCLUDE_DIR . '/test/testbootstrap.php') === false) {
throw new Exception(
'Test config params missing - copy testbootstrap-dist.php to testbootstrap.php and change'
. ' as appropriate for your own test environment setup.'
);
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
}
SendTestCase: error out when the testbootstrap file cannot be found The `PHPMailerTest` class contained a `testBootstrap()` method to verify that the `testbootstrap.php` file exists as the first test in the class. As the order in which tests are run is not predefined, this is not reliable. Additionally, the check for the `testbootstrap.php` file is checking a pre-requisite for tests using the `PHPMailer::send()` method, so it would be better to verify via a condition in the `set_up()`. Now, using such a condition, there is choice: the test can either be marked as "skipped" when the `testbootstrap.php` file can not be found, or be marked as an "error". As the tests _should_ run, skipping them would hide an error in the dev-user test setup, so showing these tests as errors seems more appropriate. To that end, the `testBootstrap()` method has been removed and a check for the `testbootstrap.php` file has been added to the `SendTestCase::set_up()` which will now throw an appropriate `Exception` when the file is not found. Oops... also removes a stray `parent::set_up()` at the start of the local `set_up()` which should have been removed in 218fd13c8867ac7342dcafc3ccdeee57eb8e5da8
2021-07-03 05:44:52 +02:00
include \PHPMAILER_INCLUDE_DIR . '/test/testbootstrap.php'; // Overrides go in here.
SendTestCase: implement use of the `$propertyChanges` property The `SendTestCase` gets the values of the properties to be set from the `testbootstrap.php` file. This introduces a `private` property to map the field names used in `$_REQUEST` to the properties in the `PHPMailer` class and adds logic to the overloaded `set_up()` method to fill the `$propertyChanges` TestCase property. The actual setting of the properties in the `PHPMailer` instance is deferred to the underlying `TestCase` parent class. Includes adding support for presetting the `bcc` value for feature completeness. Overloading and/or adding to the `$propertyChanges` array from concrete test cases is, of course, supported, so if individual tests need additional presetting of properties, the same logic as mentioned in the previous commit can be used.
2021-07-03 05:14:40 +02:00
/*
* Process the $REQUEST values and add them to the list of properties
* to change at class initialization.
*/
foreach ($this->requestKeys as $requestKey => $phpmailerKey) {
if (array_key_exists($requestKey, $_REQUEST) === false) {
continue;
}
switch ($requestKey) {
case 'mail_to':
$this->propertyChanges[$phpmailerKey] = [
'address' => $_REQUEST[$requestKey],
'name' => 'Test User',
];
break;
case 'mail_cc':
$this->propertyChanges[$phpmailerKey] = [
'address' => $_REQUEST[$requestKey],
'name' => 'Carbon User',
];
break;
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
SendTestCase: implement use of the `$propertyChanges` property The `SendTestCase` gets the values of the properties to be set from the `testbootstrap.php` file. This introduces a `private` property to map the field names used in `$_REQUEST` to the properties in the `PHPMailer` class and adds logic to the overloaded `set_up()` method to fill the `$propertyChanges` TestCase property. The actual setting of the properties in the `PHPMailer` instance is deferred to the underlying `TestCase` parent class. Includes adding support for presetting the `bcc` value for feature completeness. Overloading and/or adding to the `$propertyChanges` array from concrete test cases is, of course, supported, so if individual tests need additional presetting of properties, the same logic as mentioned in the previous commit can be used.
2021-07-03 05:14:40 +02:00
case 'mail_bcc':
$this->propertyChanges[$phpmailerKey] = [
'address' => $_REQUEST[$requestKey],
'name' => 'Blind Carbon User',
];
break;
default:
$this->propertyChanges[$phpmailerKey] = $_REQUEST[$requestKey];
break;
}
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
}
SendTestCase: implement use of the `$propertyChanges` property The `SendTestCase` gets the values of the properties to be set from the `testbootstrap.php` file. This introduces a `private` property to map the field names used in `$_REQUEST` to the properties in the `PHPMailer` class and adds logic to the overloaded `set_up()` method to fill the `$propertyChanges` TestCase property. The actual setting of the properties in the `PHPMailer` instance is deferred to the underlying `TestCase` parent class. Includes adding support for presetting the `bcc` value for feature completeness. Overloading and/or adding to the `$propertyChanges` array from concrete test cases is, of course, supported, so if individual tests need additional presetting of properties, the same logic as mentioned in the previous commit can be used.
2021-07-03 05:14:40 +02:00
// Initialize the PHPMailer class.
parent::set_up();
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
}
}
/*
* This is a sample form for setting appropriate test values through a browser
* These values can also be set using a file called testbootstrap.php (not in repo) in the same folder as this script
* which is probably more useful if you run these tests a lot
* <html>
* <body>
* <h3>PHPMailer Unit Test</h3>
* By entering a SMTP hostname it will automatically perform tests with SMTP.
*
* <form name="phpmailer_unit" action=__FILE__ method="get">
* <input type="hidden" name="submitted" value="1"/>
* From Address: <input type="text" size="50" name="mail_from" value="<?php echo get("mail_from"); ?>"/>
* <br/>
* To Address: <input type="text" size="50" name="mail_to" value="<?php echo get("mail_to"); ?>"/>
* <br/>
* Cc Address: <input type="text" size="50" name="mail_cc" value="<?php echo get("mail_cc"); ?>"/>
* <br/>
SendTestCase: implement use of the `$propertyChanges` property The `SendTestCase` gets the values of the properties to be set from the `testbootstrap.php` file. This introduces a `private` property to map the field names used in `$_REQUEST` to the properties in the `PHPMailer` class and adds logic to the overloaded `set_up()` method to fill the `$propertyChanges` TestCase property. The actual setting of the properties in the `PHPMailer` instance is deferred to the underlying `TestCase` parent class. Includes adding support for presetting the `bcc` value for feature completeness. Overloading and/or adding to the `$propertyChanges` array from concrete test cases is, of course, supported, so if individual tests need additional presetting of properties, the same logic as mentioned in the previous commit can be used.
2021-07-03 05:14:40 +02:00
* Bcc Address: <input type="text" size="50" name="mail_bcc" value="<?php echo get("mail_bcc"); ?>"/>
* <br/>
TestCase: split into three different `TestCase`s The `TestCase::set_up()` was setting quite a number of properties in the `PHPMailer` class. This makes testing more difficult for the following reasons: 1. The tests can no longer presume the properties in the `PHPMailer` class will have their default values This means that tests are not "transparent" (clearly show what is being tested), nor isolated (only target what is specifically being tested). 2. Any changes to the values set in the `set_up()` method may have a ripple effect and create a need for individual test expectations to be adjusted. 3. As the `set_up()` is changing a number of the properties using methods in the `PHPMailer()` class and methods called during the `set_up()` are included in code coverage visualizations, code coverage cannot fully be trusted and it is more difficult to verify that each piece of code has tests covering that code path. With this in mind, I'm proposing splitting the `TestCase` into three distinct abstract `TestCase`s: * A basic `TestCase` containing the utility methods and a minimal `set_up()` and `tear_down()`. * A `PreSendTestCase` for use with tests using the `preSend()` method which requires a few properties to be set. * A `SendTestCase` for use with tests actually testing the sending of mail using the `send()` method, which needs yet more properties and uses the `testbootstrap.php` file to retrieve the values of those variables. This commit executes the initial split. Follow-on commits will streamline this further. Includes adjusting the `TestCase` being extended for select existing unit test classes.
2021-07-02 05:19:50 +02:00
* SMTP Hostname: <input type="text" size="50" name="mail_host" value="<?php echo get("mail_host"); ?>"/>
* <p/>
* <input type="submit" value="Run Test"/>
*
* </form>
* </body>
* </html>
*/
Copy Permalink