Skip to content

If cleanup.php doesn't fully wipe the DB, it can cause failures. #110

Closed
#337
Closed
If cleanup.php doesn't fully wipe the DB, it can cause failures.#110
#337
Labels
ContributorDayWCUS26enhancementhelp wanted

Description

@Ipstenu
Ipstenu
opened on Feb 25, 2020

There's really no other place to post these errors. I get them running the normal tests. Nothing on my end changed that I know of. I've tried upgrading all the things.

  1. Tests_User_Capabilities::test_all_caps_of_users_are_being_tested
    User with administrator role has capabilities that aren't being tested
    Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
+    59 => 'export_others_personal_data'
+    60 => 'erase_others_personal_data'
+    61 => 'manage_privacy_options'
 )

/phpunit-test-runner/wp-test-runner/tests/phpunit/tests/user/capabilities.php:381

  1. Tests_User_Capabilities::testPrimitiveCapsTestsAreCorrect
    These primitive capabilities are not tested
Failed asserting that Array &0 (
    59 => 'export_others_personal_data'
    60 => 'erase_others_personal_data'
    61 => 'manage_privacy_options'
) is identical to Array &0 ().

/phpunit-test-runner/wp-test-runner/tests/phpunit/tests/user/capabilities.php:423

I'm not sure how/where this broke (I was out for a while)

Activity

  1. Ipstenu commented on Feb 25, 2020

    @Ipstenu
    Ipstenu
    on Feb 25, 2020
    Author

    Okay it LOOKS like cleanup.php isn't nuking the DB tables, which I thought it was supposed to?

  2. Ipstenu commented on Feb 25, 2020

    @Ipstenu
    Ipstenu
    on Feb 25, 2020
    Author

    Confirmed. Once I wiped out the database and let it rebuild clean, it was fine. So yeah, that;'s a thing,

  3. Ipstenu
    changed the title [-]Failure: test_all_caps_of_users_are_being_tested failed on 'extra' caps found[/-] [+]If cleanup.php doesn't fully wipe the DB, it can cause failures.[/+] on Feb 25, 2020

  4. getsource commented on Feb 26, 2020

    @getsource
    getsource
    on Feb 26, 2020
    Member

    Thanks @Ipstenu ! In core, manual cleanup isn't necessary (as far as I'm aware), so I'm wondering what might be different in this particular case.

  5. Ipstenu commented on Feb 26, 2020

    @Ipstenu
    Ipstenu
    on Feb 26, 2020
    Author

    The best guess I have is that somehow something was corrupted, and since the cleanup doesn't wipe the DB, there it stayed. Usually the DB changes are additive to WP, but it might be smart to tweak that in advance of DB changes down the road.

  6. timbutler commented on Feb 27, 2020

    @timbutler
    timbutler
    on Feb 27, 2020
    Contributor

    I can confirm this was the error with the Conetix tests failing as well. Manually deleting the database tables and re-running corrected the issue.

  7. getsource
    added
    enhancement
    help wanted
    on Feb 27, 2020
  8. mrxkon
    added a commit that references this issue on Jan 12, 2021

    drop test tables on cleanup

    99ae3e7

  9. mrxkon commented on Jan 12, 2021

    @mrxkon
    mrxkon
    on Jan 12, 2021
    Contributor

    I've been using the code in #138 on my setups since i also wanted a clean start always. Most likely it's fine as it is to be merged & used in general (no issues on my end at least 😁 ) but feel free to point out any extra ideas.

    I didn't want to go via a $wpdb route as including wp-load or anything like that would most likely start to return warnings for headers etc and wanted an as clean as possible output for logging so I decided to just go for a pretty straightforward mysqli way.

    Note I've been using this on "local" setups, not sure if the remote setup would need something different (and I have no way to test it atm).

  10. kittenkamala
    added
    ContributorDay
    on May 7, 2025
  11. kittenkamala
    added
    WCUS26
    on Jun 2, 2026
  12. kittenkamala
    moved this to In progress in Hosting Team WCUS 2026on Jul 30, 2026
  13. kittenkamala
    added this to Hosting Team WCUS 2026on Jul 30, 2026

  14. ekamran commented on Aug 27, 2026

    @ekamran
    ekamran
    on Aug 27, 2026
    Contributor

    I was able to reproduce this on current trunk, so this is still valid.

    The stale data survives because WordPress boots before the test tables are dropped in tests/phpunit/includes/install.php. Data such as user roles can already be loaded into memory, and then gets written back into the fresh tables.

    For the repro, I added one extra capability to the administrator role directly in the database and ran the suite normally. It produced the same failure from the original report, and dropping the test tables before the run fixed it.

    #138 goes in the right direction, but two gaps showed up while testing: with WPT_SSH_CONNECT, cleanup needs to run where the tests ran, and a database cleanup failure should not stop file cleanup. I am opening a PR that handles those cases, drops all base tables matching the configured test prefix, includes multisite sub-site tables like wptests_2_posts, leaves unrelated tables untouched, and keeps the database password off the command line.

  15. jazzsequence
    added a commit that references this issue on Sep 16, 2026

    Drop the test tables from the database during cleanup

    6538f85
  16. jazzsequence
    closed this as completedin #337on Sep 16, 2026
  17. github-project-automation
    moved this from In progress to Done in Hosting Team WCUS 2026on Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ContributorDayWCUS26enhancementhelp wanted

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions