tests/e2e/helpers/custom-db-simulator-mu-plugin.php (2)

14-17: Use Yoda condition for consistency.

The comparison should use Yoda-style to match the project's PHP coding guidelines.

♻️ Proposed fix

 add_filter('slimstat_custom_wpdb', function ($current_wpdb) {
-    if (get_option('slimstat_test_use_custom_db') !== 'yes') {
+    if ('yes' !== get_option('slimstat_test_use_custom_db')) {
         return $current_wpdb;
     }

As per coding guidelines: "Use Yoda Conditions: if ( 'value' === $var )"

🤖 Prompt for AI Agents

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

In `@tests/e2e/helpers/custom-db-simulator-mu-plugin.php` around lines 14 - 17,
Change the conditional inside the anonymous function passed to
add_filter('slimstat_custom_wpdb') to use a Yoda condition: invert the
comparison so the literal 'yes' is on the left and the result of
get_option('slimstat_test_use_custom_db') is on the right (i.e., use 'yes' ===
get_option(...)); update the early-return branch accordingly in that closure.

---

1-12: Add GPL license header to this new PHP file.

Per coding guidelines, all new PHP files should include a GPL license header. Consider adding the standard WordPress GPL header block.

📝 Suggested header addition

 <?php
+/*
+ * Plugin Name: Custom DB Simulator (E2E Test Only)
+ * Description: Simulates the slimstat_custom_wpdb filter for E2E testing.
+ * License: GPL-2.0-or-later
+ * License URI: https://www.gnu.org/licenses/gpl-2.0.html
+ */
 /**
  * MU-Plugin: Custom DB Simulator
  *

🤖 Prompt for AI Agents

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

In `@tests/e2e/helpers/custom-db-simulator-mu-plugin.php` around lines 1 - 12, Add
the standard WordPress GPL license header block to the top of the new MU-Plugin
file (the comment beginning "MU-Plugin: Custom DB Simulator" in
custom-db-simulator-mu-plugin.php). Insert the canonical PHP GPL header (short
copyright line, Copyright holder/year, a brief description, "This program is
free software; you can redistribute it and/or modify it under the terms of the
GNU General Public License" and the license URL) immediately above or replacing
the existing file comment so the file complies with coding guidelines.

tests/e2e/databuckets-custom-db-accuracy.spec.ts (2)

167-176: Minor: Timestamps are computed at module load time.

The range timestamps (now, rangeStart, rangeEnd, week*Ts) are computed when the file loads rather than when tests execute. If there's significant delay between loading and execution, the "now" could be slightly stale. This is unlikely to cause issues given the 3-week range buffer, but worth noting.

If flaky behavior ever occurs with time-sensitive tests, consider moving these calculations into a beforeAll hook or computing them fresh in each test.

🤖 Prompt for AI Agents

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

In `@tests/e2e/databuckets-custom-db-accuracy.spec.ts` around lines 167 - 176,
Timestamps like now, rangeStart, rangeEnd, week1Ts, week2Ts, week3Ts are
computed at module load time which can drift before test execution; move their
calculations into a dynamic setup (e.g., a beforeAll hook or compute inside each
test) so values are fresh when tests run, update any test usages to reference
the new variables (or call a helper that returns them) so week, now and the
week*Ts are derived at runtime rather than module import time.

---

405-409: Assertion may be overly permissive for the off-by-one fix validation.

The comment states "v1 array length should match labels length" but the assertion uses toBeLessThanOrEqual. Based on the DataBuckets::initSeq code (which creates labels and datasets in lock-step), after the fix they should always be equal. A stricter assertion would more precisely validate the fix.

♻️ Suggested stricter assertion

     // Verify no extra phantom datasets beyond label count
     const labels: string[] = json?.data?.data?.labels ?? [];
     const v1Array: number[] = json?.data?.data?.datasets?.v1 ?? [];
     // After the fix, v1 array length should match labels length
-    expect(v1Array.length).toBeLessThanOrEqual(labels.length);
+    expect(v1Array.length).toBe(labels.length);

🤖 Prompt for AI Agents

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

In `@tests/e2e/databuckets-custom-db-accuracy.spec.ts` around lines 405 - 409, The
test currently asserts v1Array.length is <= labels.length but should assert
exact equality to validate the off-by-one fix; update the assertion in
tests/e2e/databuckets-custom-db-accuracy.spec.ts to compare v1Array.length ===
labels.length (referencing the labels and v1Array variables and the
DataBuckets::initSeq behavior) so the test fails if datasets and labels are not
created in lock-step.

tests/e2e/exclusion-filters.spec.ts (1)

126-126: Prefer polling the DB over fixed 4s sleeps.

These waits are both the slowest part of the file and still timing-sensitive under CI variance. expect.poll() against getRecentStatByResource() / getStatCount() will make the assertions deterministic.

⏱️ Example refactor

-    await anonPage.waitForTimeout(4000);
-
-    const stat = await getRecentStatByResource(slug);
-    expect(stat).toBeNull();
+    await expect.poll(() => getRecentStatByResource(slug)).toBeNull();

-    await anonPage.waitForTimeout(4000);
-    const countAfter = await getStatCount();
-    expect(countAfter).toBe(countBefore);
+    await expect.poll(() => getStatCount()).toBe(countBefore);

Also applies to: 158-158, 191-191, 216-216, 249-249

🤖 Prompt for AI Agents

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

In `@tests/e2e/exclusion-filters.spec.ts` at line 126, Replace fixed sleeps (await
anonPage.waitForTimeout(4000)) with polling assertions using expect.poll()
against the helper functions (getRecentStatByResource() or getStatCount()) so
tests wait until the DB reaches the expected state; locate each occurrence of
await anonPage.waitForTimeout (lines where 4000 is used) and change to an
expect.poll(() => getRecentStatByResource(...)) or expect.poll(() =>
getStatCount(...)).toHave... with a reasonable timeout and interval so the
assertion becomes deterministic under CI variance.

tests/e2e/exclusion-filters.spec.ts (1)

75-83: Unused postId return value.

createProductPost() returns the inserted post ID, but callers on lines 117 and 151 assign it to postId without using it. Either remove the assignment or add assertions to verify the correct post was created.

♻️ Option 1: Remove unused assignment

     // Create product post via direct DB insert
     const slug = `e2e-cpt-excl-${Date.now()}`;
-    const postId = await createProductPost('E2E CPT Exclusion Test', slug);
+    await createProductPost('E2E CPT Exclusion Test', slug);

Also applies to: 115-117, 149-151

🤖 Prompt for AI Agents

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

In `@tests/e2e/exclusion-filters.spec.ts` around lines 75 - 83, The helper
createProductPost returns the inserted post ID but the callers that call
createProductPost (assigning to postId) never use that value; either stop
assigning the unused return or actually assert the created post ID/row exists.
Update the test calls that invoke createProductPost (remove the "const postId =
" assignment) or replace the assignment with an assertion that validates the
insert (e.g., check result.insertId is a number or query wp_posts by ID/title)
and keep createProductPost as-is to return the ID for verification.