woocommerce/tests/php/includes/settings/class-wc-settings-accounts-...

142 lines
5.9 KiB
PHP
Raw Normal View History

Refactor the settings pages, and add unit tests for them. This commit fixes some inconsistencies in the settings pages, and makes all the existing pages extensible by adding new sections (that was possible in some pages, but not in others). Main changes: 1. Modify the 'get_sections' method so that it invokes a new protected 'get_own_sections' method and then triggers the 'woocommerce_get_sections_' . id filter. This way the filter is triggered only in the base class and not in each of the derived classes too. 2. Change the get_settings() method so that it has its signature changed to get_settings( $current_section = '' ) in the base class and in all the derived class. Some derived classes were already using this signature, but others (those not having multiple sections natively) weren't, making then effectively impossible to define multiple sections for these pages via filters. With this change all the section pages act consistently and allow both adding new settings to the default "General" section and creating new sections via filters. 3. Change the implementation of 'get_settings' in the base class so that it searches for a 'get_settings_for_{section_id}_section' method in the class and executes it, otherwise it executes the new protected method get_settings_for_section( $current_section ); then it triggers the 'woocommerce_get_settings_' . id filter. This makes it easier to separate the code that returns the list of filters in multiple methods, one per section, instead of using one big if-else-else... block. So now instead of overriding get_settings($current_section='') derived classes need to implement get_settings_for_{$current_section}_section for each section, or override get_settings_for_section($current_section) or both. 'get_settings_for_section' returns an empty array by default. Also, 'woocommerce_get_settings_' . id is triggered in one single place too. Other improvements: * Remove duplicated code from 'output' in 'WC_Settings_Page' children. Some classes inherited from 'WC_Settings_Page' override the 'output' method with custom code, which in all cases ended up repeating the code of the original method as a fallback. These repetitions have been replaced with 'parent::output()'. * Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some inconsistencies in their 'save' and 'output' methods that prevented the proper creation new sections and the addition of new settings via the 'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters. Now they work as expected. * Deduplicate parts of 'save' in 'WC_Settings_Page' and children. Two methods have been added to 'WC_Settings_Page' class: 'save_settings_for_current_section' and 'do_update_options_action'. These are intended to be invoked by derived classes in their 'save' methods, in order to remove code repetition. * Add some helper methods to WC_Unit_Test_Case. Methods added: - assertOutputsHTML - assertEqualsHTML - normalize_html - capture_output_from
2020-09-16 10:27:05 +00:00
<?php
/**
* Class WC_Settings_Accounts_Test file.
*
* @package WooCommerce\Tests\Settings
*/
use Automattic\WooCommerce\Testing\Tools\CodeHacking\Hacks\FunctionsMockerHack;
require_once __DIR__ . '/class-wc-settings-unit-test-case.php';
/**
* Unit tests for the WC_Settings_General class.
*/
class WC_Settings_Accounts_Test extends WC_Settings_Unit_Test_Case {
/**
* Test for get_settings (triggers the woocommerce_account_settings filter).
*/
public function test_get_settings__triggers_filter() {
$actual_settings_via_filter = null;
add_filter(
'woocommerce_account_settings',
function( $settings ) use ( &$actual_settings_via_filter ) {
$actual_settings_via_filter = $settings;
return $settings;
},
10,
1
);
$sut = new WC_Settings_Accounts();
$actual_settings_returned = $sut->get_settings_for_section( '' );
Refactor the settings pages, and add unit tests for them. This commit fixes some inconsistencies in the settings pages, and makes all the existing pages extensible by adding new sections (that was possible in some pages, but not in others). Main changes: 1. Modify the 'get_sections' method so that it invokes a new protected 'get_own_sections' method and then triggers the 'woocommerce_get_sections_' . id filter. This way the filter is triggered only in the base class and not in each of the derived classes too. 2. Change the get_settings() method so that it has its signature changed to get_settings( $current_section = '' ) in the base class and in all the derived class. Some derived classes were already using this signature, but others (those not having multiple sections natively) weren't, making then effectively impossible to define multiple sections for these pages via filters. With this change all the section pages act consistently and allow both adding new settings to the default "General" section and creating new sections via filters. 3. Change the implementation of 'get_settings' in the base class so that it searches for a 'get_settings_for_{section_id}_section' method in the class and executes it, otherwise it executes the new protected method get_settings_for_section( $current_section ); then it triggers the 'woocommerce_get_settings_' . id filter. This makes it easier to separate the code that returns the list of filters in multiple methods, one per section, instead of using one big if-else-else... block. So now instead of overriding get_settings($current_section='') derived classes need to implement get_settings_for_{$current_section}_section for each section, or override get_settings_for_section($current_section) or both. 'get_settings_for_section' returns an empty array by default. Also, 'woocommerce_get_settings_' . id is triggered in one single place too. Other improvements: * Remove duplicated code from 'output' in 'WC_Settings_Page' children. Some classes inherited from 'WC_Settings_Page' override the 'output' method with custom code, which in all cases ended up repeating the code of the original method as a fallback. These repetitions have been replaced with 'parent::output()'. * Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some inconsistencies in their 'save' and 'output' methods that prevented the proper creation new sections and the addition of new settings via the 'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters. Now they work as expected. * Deduplicate parts of 'save' in 'WC_Settings_Page' and children. Two methods have been added to 'WC_Settings_Page' class: 'save_settings_for_current_section' and 'do_update_options_action'. These are intended to be invoked by derived classes in their 'save' methods, in order to remove code repetition. * Add some helper methods to WC_Unit_Test_Case. Methods added: - assertOutputsHTML - assertEqualsHTML - normalize_html - capture_output_from
2020-09-16 10:27:05 +00:00
remove_all_filters( 'woocommerce_account_settings' );
$this->assertSame( $actual_settings_returned, $actual_settings_via_filter );
}
/**
* Test for get_settings (all settings are present).
*/
public function test_get_settings__all_settings_are_present() {
$sut = new WC_Settings_Accounts();
$settings = $sut->get_settings_for_section( '' );
Refactor the settings pages, and add unit tests for them. This commit fixes some inconsistencies in the settings pages, and makes all the existing pages extensible by adding new sections (that was possible in some pages, but not in others). Main changes: 1. Modify the 'get_sections' method so that it invokes a new protected 'get_own_sections' method and then triggers the 'woocommerce_get_sections_' . id filter. This way the filter is triggered only in the base class and not in each of the derived classes too. 2. Change the get_settings() method so that it has its signature changed to get_settings( $current_section = '' ) in the base class and in all the derived class. Some derived classes were already using this signature, but others (those not having multiple sections natively) weren't, making then effectively impossible to define multiple sections for these pages via filters. With this change all the section pages act consistently and allow both adding new settings to the default "General" section and creating new sections via filters. 3. Change the implementation of 'get_settings' in the base class so that it searches for a 'get_settings_for_{section_id}_section' method in the class and executes it, otherwise it executes the new protected method get_settings_for_section( $current_section ); then it triggers the 'woocommerce_get_settings_' . id filter. This makes it easier to separate the code that returns the list of filters in multiple methods, one per section, instead of using one big if-else-else... block. So now instead of overriding get_settings($current_section='') derived classes need to implement get_settings_for_{$current_section}_section for each section, or override get_settings_for_section($current_section) or both. 'get_settings_for_section' returns an empty array by default. Also, 'woocommerce_get_settings_' . id is triggered in one single place too. Other improvements: * Remove duplicated code from 'output' in 'WC_Settings_Page' children. Some classes inherited from 'WC_Settings_Page' override the 'output' method with custom code, which in all cases ended up repeating the code of the original method as a fallback. These repetitions have been replaced with 'parent::output()'. * Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some inconsistencies in their 'save' and 'output' methods that prevented the proper creation new sections and the addition of new settings via the 'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters. Now they work as expected. * Deduplicate parts of 'save' in 'WC_Settings_Page' and children. Two methods have been added to 'WC_Settings_Page' class: 'save_settings_for_current_section' and 'do_update_options_action'. These are intended to be invoked by derived classes in their 'save' methods, in order to remove code repetition. * Add some helper methods to WC_Unit_Test_Case. Methods added: - assertOutputsHTML - assertEqualsHTML - normalize_html - capture_output_from
2020-09-16 10:27:05 +00:00
$settings_ids_and_types = $this->get_ids_and_types( $settings );
$expected = array(
'account_registration_options' => array( 'title', 'sectionend' ),
'woocommerce_enable_guest_checkout' => 'checkbox',
'woocommerce_enable_checkout_login_reminder' => 'checkbox',
'woocommerce_enable_signup_and_login_from_checkout' => 'checkbox',
'woocommerce_enable_myaccount_registration' => 'checkbox',
'woocommerce_registration_generate_username' => 'checkbox',
'woocommerce_registration_generate_password' => 'checkbox',
'woocommerce_erasure_request_removes_order_data' => 'checkbox',
'woocommerce_erasure_request_removes_download_data' => 'checkbox',
'woocommerce_allow_bulk_remove_personal_data' => 'checkbox',
'privacy_policy_options' => array( 'title', 'sectionend' ),
'woocommerce_registration_privacy_policy_text' => 'textarea',
'woocommerce_checkout_privacy_policy_text' => 'textarea',
'personal_data_retention' => array( 'title', 'sectionend' ),
'woocommerce_delete_inactive_accounts' => 'relative_date_selector',
'woocommerce_trash_pending_orders' => 'relative_date_selector',
'woocommerce_trash_failed_orders' => 'relative_date_selector',
'woocommerce_trash_cancelled_orders' => 'relative_date_selector',
'woocommerce_anonymize_completed_orders' => 'relative_date_selector',
);
$this->assertEquals( $expected, $settings_ids_and_types );
Refactor the settings pages, and add unit tests for them. This commit fixes some inconsistencies in the settings pages, and makes all the existing pages extensible by adding new sections (that was possible in some pages, but not in others). Main changes: 1. Modify the 'get_sections' method so that it invokes a new protected 'get_own_sections' method and then triggers the 'woocommerce_get_sections_' . id filter. This way the filter is triggered only in the base class and not in each of the derived classes too. 2. Change the get_settings() method so that it has its signature changed to get_settings( $current_section = '' ) in the base class and in all the derived class. Some derived classes were already using this signature, but others (those not having multiple sections natively) weren't, making then effectively impossible to define multiple sections for these pages via filters. With this change all the section pages act consistently and allow both adding new settings to the default "General" section and creating new sections via filters. 3. Change the implementation of 'get_settings' in the base class so that it searches for a 'get_settings_for_{section_id}_section' method in the class and executes it, otherwise it executes the new protected method get_settings_for_section( $current_section ); then it triggers the 'woocommerce_get_settings_' . id filter. This makes it easier to separate the code that returns the list of filters in multiple methods, one per section, instead of using one big if-else-else... block. So now instead of overriding get_settings($current_section='') derived classes need to implement get_settings_for_{$current_section}_section for each section, or override get_settings_for_section($current_section) or both. 'get_settings_for_section' returns an empty array by default. Also, 'woocommerce_get_settings_' . id is triggered in one single place too. Other improvements: * Remove duplicated code from 'output' in 'WC_Settings_Page' children. Some classes inherited from 'WC_Settings_Page' override the 'output' method with custom code, which in all cases ended up repeating the code of the original method as a fallback. These repetitions have been replaced with 'parent::output()'. * Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some inconsistencies in their 'save' and 'output' methods that prevented the proper creation new sections and the addition of new settings via the 'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters. Now they work as expected. * Deduplicate parts of 'save' in 'WC_Settings_Page' and children. Two methods have been added to 'WC_Settings_Page' class: 'save_settings_for_current_section' and 'do_update_options_action'. These are intended to be invoked by derived classes in their 'save' methods, in order to remove code repetition. * Add some helper methods to WC_Unit_Test_Case. Methods added: - assertOutputsHTML - assertEqualsHTML - normalize_html - capture_output_from
2020-09-16 10:27:05 +00:00
}
/**
* Data provider for test_linked_text_for_erasure_request_settings.
*
* @return array[]
*/
public function data_provider_for_test_linked_text_for_erasure_request_settings() {
return array(
array(
false,
null,
'When handling an account erasure request, should personal data within orders be retained or removed?',
'When handling an account erasure request, should access to downloadable files be revoked and download logs cleared?',
),
array(
true,
'5.2',
'When handling an <a href="http://example.org/wp-admin/tools.php?page=remove_personal_data">account erasure request</a>, should personal data within orders be retained or removed?',
'When handling an <a href="http://example.org/wp-admin/tools.php?page=remove_personal_data">account erasure request</a>, should access to downloadable files be revoked and download logs cleared?',
),
array(
true,
'5.3',
'When handling an <a href="http://example.org/wp-admin/erase-personal-data.php">account erasure request</a>, should personal data within orders be retained or removed?',
'When handling an <a href="http://example.org/wp-admin/erase-personal-data.php">account erasure request</a>, should access to downloadable files be revoked and download logs cleared?',
),
);
}
/**
* Test that the "account erasure request" text is linked or not as appropriate for descriptions of account erasure request related options.
*
* @dataProvider data_provider_for_test_linked_text_for_erasure_request_settings
*
* @param bool $current_user_can_manage_privacy_options Can the current user manage privacy options?.
* @param string $blog_version Current blog version.
* @param string $expected_order_erasure_text Expected description for the remove order data option.
* @param string $expected_downloads_erasure_text Expected description for the remove downloads data option.
*/
public function test_linked_text_for_erasure_request_settings( $current_user_can_manage_privacy_options, $blog_version, $expected_order_erasure_text, $expected_downloads_erasure_text ) {
FunctionsMockerHack::add_function_mocks(
array(
'current_user_can' => function( $capability, ...$args ) use ( $current_user_can_manage_privacy_options ) {
return 'manage_privacy_options' === $capability ?
$current_user_can_manage_privacy_options :
current_user_can( $capability, ...$args );
},
'get_bloginfo' => function( $show = '', $filter = 'raw' ) use ( $blog_version ) {
return 'version' === $show ?
$blog_version :
get_bloginfo( $show, $filter );
},
)
);
$sut = new WC_Settings_Accounts();
$settings = $sut->get_settings_for_section( '' );
Refactor the settings pages, and add unit tests for them. This commit fixes some inconsistencies in the settings pages, and makes all the existing pages extensible by adding new sections (that was possible in some pages, but not in others). Main changes: 1. Modify the 'get_sections' method so that it invokes a new protected 'get_own_sections' method and then triggers the 'woocommerce_get_sections_' . id filter. This way the filter is triggered only in the base class and not in each of the derived classes too. 2. Change the get_settings() method so that it has its signature changed to get_settings( $current_section = '' ) in the base class and in all the derived class. Some derived classes were already using this signature, but others (those not having multiple sections natively) weren't, making then effectively impossible to define multiple sections for these pages via filters. With this change all the section pages act consistently and allow both adding new settings to the default "General" section and creating new sections via filters. 3. Change the implementation of 'get_settings' in the base class so that it searches for a 'get_settings_for_{section_id}_section' method in the class and executes it, otherwise it executes the new protected method get_settings_for_section( $current_section ); then it triggers the 'woocommerce_get_settings_' . id filter. This makes it easier to separate the code that returns the list of filters in multiple methods, one per section, instead of using one big if-else-else... block. So now instead of overriding get_settings($current_section='') derived classes need to implement get_settings_for_{$current_section}_section for each section, or override get_settings_for_section($current_section) or both. 'get_settings_for_section' returns an empty array by default. Also, 'woocommerce_get_settings_' . id is triggered in one single place too. Other improvements: * Remove duplicated code from 'output' in 'WC_Settings_Page' children. Some classes inherited from 'WC_Settings_Page' override the 'output' method with custom code, which in all cases ended up repeating the code of the original method as a fallback. These repetitions have been replaced with 'parent::output()'. * Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some inconsistencies in their 'save' and 'output' methods that prevented the proper creation new sections and the addition of new settings via the 'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters. Now they work as expected. * Deduplicate parts of 'save' in 'WC_Settings_Page' and children. Two methods have been added to 'WC_Settings_Page' class: 'save_settings_for_current_section' and 'do_update_options_action'. These are intended to be invoked by derived classes in their 'save' methods, in order to remove code repetition. * Add some helper methods to WC_Unit_Test_Case. Methods added: - assertOutputsHTML - assertEqualsHTML - normalize_html - capture_output_from
2020-09-16 10:27:05 +00:00
$order_data_removal_setting = $this->setting_by_id( $settings, 'woocommerce_erasure_request_removes_order_data' );
$actual_desc = $order_data_removal_setting['desc_tip'];
$this->assertEquals( $expected_order_erasure_text, $actual_desc );
$downloads_data_removal_setting = $this->setting_by_id( $settings, 'woocommerce_erasure_request_removes_download_data' );
$actual_desc = $downloads_data_removal_setting['desc_tip'];
$this->assertEquals( $expected_downloads_erasure_text, $actual_desc );
}
}