plugins/woocommerce/tests/php/src/Admin/API/Reports/Taxes/ControllerTest.php (1)

86-117: Consider adding a test for default export item structure.

The Revenue Stats ControllerTest includes a test_prepare_item_for_export_returns_defaults test that validates the default export row structure. This Taxes test suite is missing that equivalent test, which would verify that prepare_item_for_export returns the expected default fields (tax_code, rate, total_tax, etc.) before any filters are applied.

Adding this test would ensure consistent coverage across all report controller test suites.

💡 Suggested test to add

/**
 * `@testdox` prepare_item_for_export returns the default export row.
 */
public function test_prepare_item_for_export_returns_defaults(): void {
    $item = array(
        'tax_rate_id'  => 1,
        'country'      => 'US',
        'state'        => 'CA',
        'name'         => 'State Tax',
        'priority'     => 1,
        'tax_rate'     => '8.25',
        'total_tax'    => 82.50,
        'order_tax'    => 75.00,
        'shipping_tax' => 7.50,
        'orders_count' => 10,
    );

    $export_item = $this->sut->prepare_item_for_export( $item );

    $this->assertArrayHasKey( 'tax_code', $export_item );
    $this->assertArrayHasKey( 'rate', $export_item );
    $this->assertArrayHasKey( 'total_tax', $export_item );
    $this->assertArrayHasKey( 'order_tax', $export_item );
    $this->assertArrayHasKey( 'shipping_tax', $export_item );
    $this->assertArrayHasKey( 'orders_count', $export_item );
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@plugins/woocommerce/tests/php/src/Admin/API/Reports/Taxes/ControllerTest.php`
around lines 86 - 117, Add a new unit test in ControllerTest that verifies
prepare_item_for_export returns the expected default export fields before
filters run: create a test method (e.g.,
test_prepare_item_for_export_returns_defaults) that builds a representative
$item array (matching the one used in
test_prepare_item_for_export_filter_can_add_column), calls
$this->sut->prepare_item_for_export($item), and asserts the presence of keys
like 'tax_code', 'rate', 'total_tax', 'order_tax', 'shipping_tax', and
'orders_count' in the returned $export_item; place the test alongside the
existing tests so it runs with the same setup/teardown and does not rely on
add_filter.

plugins/woocommerce/client/admin/client/analytics/components/report-table/test/utils.js (1)

67-97: Add one malformed-extension config case.

These cases only exercise well-formed filters / advancedFilters, but this helper now consumes extension-provided report config. Please add a defensive test for missing settings, non-array filters, or non-object advancedFilters.filters so a bad plugin config can't break exports.

🧪 Suggested test

+	it( 'ignores malformed extension filter config', () => {
+		const reportQuery = { orderby: 'date' };
+		const urlQuery = { currency: 'EUR', status: 'completed' };
+		const filters = [
+			{ param: 'currency' },
+			{
+				param: 'filter',
+				filters: [ {}, { value: 'single', settings: null } ],
+			},
+		];
+		const advancedFilters = { filters: null };
+
+		expect( () =>
+			getExportQuery( reportQuery, urlQuery, filters, advancedFilters )
+		).not.toThrow();
+		expect(
+			getExportQuery( reportQuery, urlQuery, filters, advancedFilters )
+		).toMatchObject( {
+			orderby: 'date',
+			currency: 'EUR',
+		} );
+	} );

As per coding guidelines, "Don't trust that extension developers will follow the best practices, make sure the code: Guards against unexpected inputs."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@plugins/woocommerce/client/admin/client/analytics/components/report-table/test/utils.js`
around lines 67 - 97, Add a defensive unit test in
plugins/woocommerce/client/admin/client/analytics/components/report-table/test/utils.js
that calls getExportQuery with malformed extension config (e.g., a filter object
missing settings, a filters value that is not an array, and advancedFilters with
filters not being an object) and asserts the call does not throw and that no
unexpected params are added (e.g., result does not contain keys from the
malformed entries); reference getExportQuery and reuse the existing test pattern
(create reportQuery and urlQuery, pass malformed filters/advancedFilters, call
getExportQuery, expect no exception and expect result to only include valid
params).

plugins/woocommerce/client/admin/client/analytics/components/report-table/utils.js (1)

74-79: Consider whether null values should also be excluded.

The filter excludes undefined and empty strings, but null would pass through. URL params are typically strings, so this is unlikely to matter in practice, but for completeness:

 ( [ key, value ] ) =>
     filterParamKeys.has( key ) &&
     ! ( key in safeReportQuery ) &&
     value !== undefined &&
+    value !== null &&
     value !== ''

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@plugins/woocommerce/client/admin/client/analytics/components/report-table/utils.js`
around lines 74 - 79, The current predicate used to filter params (the arrow
callback checking filterParamKeys.has(key), !(key in safeReportQuery), value !==
undefined, and value !== '') will allow null values; update this predicate to
also exclude null (add value !== null) so that null params are not included in
URL/query generation — locate the filter using filterParamKeys, safeReportQuery
and the arrow function shown and add the null check to the combined conditions.

plugins/woocommerce/tests/php/src/Admin/API/Reports/Taxes/ControllerTest.php (1)

89-116: Add a baseline prepare_item_for_export() test.

Right now this only verifies that the hook can extend the row. It would be good to also assert the unfiltered default export item so a regression in the existing tax columns or formatting is caught directly.

As per coding guidelines, "Add unit or E2E tests where applicable".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@plugins/woocommerce/tests/php/src/Admin/API/Reports/Taxes/ControllerTest.php`
around lines 89 - 116, Add a baseline assertion for prepare_item_for_export to
verify the unfiltered default export row before/without filter modifications:
call $this->sut->prepare_item_for_export($item) in a new test or at the start of
test_prepare_item_for_export_filter_can_add_column and assert the expected
default keys and values (e.g. presence of tax_rate_id, country, state, name,
priority, tax_rate, total_tax, order_tax, shipping_tax, orders_count) and that
numeric/formatted fields match the expected unfiltered output; use the
prepare_item_for_export method and add a separate test name like
test_prepare_item_for_export_defaults or add assertions prior to adding the
filter so regressions in default columns/formatting are caught.

plugins/woocommerce/tests/php/src/Admin/API/Reports/Variations/ControllerTest.php (1)

88-116: Add a baseline prepare_item_for_export() test.

These assertions only prove the hook can append a field. A regression in the default row mapping or number formatting would still pass here, so it would be worth adding one unfiltered baseline test like the revenue suite has.

As per coding guidelines, "Add unit or E2E tests where applicable".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@plugins/woocommerce/tests/php/src/Admin/API/Reports/Variations/ControllerTest.php`
around lines 88 - 116, Add a baseline unfiltered unit test for
prepare_item_for_export that verifies the default row mapping and number
formatting (not just hook behavior): create a new test method (e.g.,
test_prepare_item_for_export_defaults) that calls
$this->sut->prepare_item_for_export with a representative $item (same shape used
in test_prepare_item_for_export_filter_can_add_column) without adding any
add_filter, then assert the expected default keys exist (e.g., 'items_sold',
'net_revenue', 'orders_count', and values from 'extended_info' like 'name' and
'sku') and assert net_revenue is formatted/returned as the expected
numeric/string representation used elsewhere in the suite; place this alongside
the existing test so regressions in the default mapping/formatting are caught.