Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 years ago

#5038 closed defect (bug) (fixed)

Unit tests do not clear DB entries when finished

Reported by: r-a-y's profile r-a-y Owned by: boonebgorges's profile boonebgorges
Milestone: 1.8 Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch commit
Cc:

Description

As I was testing a few unit tests, I noticed that we never wipe any of BP's entries from the DB.

I've attached a first pass at clearing them, but am wondering if it's the right approach.

Attachments (2)

5038.01.patch (4.2 KB) - added by r-a-y 12 years ago.
5038.02.patch (358 bytes) - added by r-a-y 12 years ago.

Download all attachments as: .zip

Change History (11)

@r-a-y
12 years ago

#1 @boonebgorges
12 years ago

I thought the WP test suite used transaction rollbacks to remove all test-related data between each testcase. If there were lots of BP data left over, a lot of the tests would probably fail. Are you finding that's the case?

#2 @r-a-y
12 years ago

Some tests were failing for me and as I was exploring through the DB, I noticed that the data was still there.

Here's what I'm using as a test:

phpunit --group groups

Try running this twice if you don't get any failed unit tests.

Then check the BP group DB tables. Do you see any DB entries?

WP deletes its test data with _delete_all_posts(). Which is probably why I'm not seeing any of its data in the DB after running a WP unit test.

It could be that my rig is not setup properly for transaction rollbacks (I haven't looked into this yet), which is why I need a 2nd-opinion.

#3 @boonebgorges
12 years ago

Hm, interesting. I can run phpunit --group-groups over and over (and over!) with no problem. When the tests are finished, all the BP tables are empty.

From my (albeit incomplete) understanding, the reason why _delete_all_posts() is necessary is because of the WP installation process. It creates a Sample Page and a Hello World post. But since this takes place during the WP install, and not during a test, transactions don't help with the rollback. So it's sort of a special case that doesn't extend to BP data.

So, the mystery remains. What's your rig like? Mine:

  • PHPUnit 3.7.13
  • mysql - ver 15.1 distrib 5.5.31-MariaDB
  • wp-unit-tests rev 1249

#4 @boonebgorges
12 years ago

quick update - I svn upped my wp-unit-tests to rev1293 and it's still working as expected.

#5 @r-a-y
12 years ago

I'm running:

  • PHPUnit 3.7.10
  • MySQL 5.5.29-community
  • wp-unit-tests r1293

I just checked the BP DB tables and they are MyISAM, while the WP tables are InnoDB. I believe this may be the issue.

Boone, can you verify if your BP tables are InnoDB or MyISAM? A quick Google search told me that rollback isn't supported in MyISAM.

@r-a-y
12 years ago

#6 @r-a-y
12 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 1.8

And we have lift-off!

See 02.patch. Needed to explicitly set InnoDB as the storage type during BP install.

This is similar to how WP does it:
https://core.trac.wordpress.org/browser/tests/trunk/includes/install.php#L36

#7 @DJPaul
12 years ago

Interesting how my test's tables were/are already InnoDB. Maybe my config has a different default.

#8 @boonebgorges
12 years ago

  • Keywords commit added

Nice! Good catch, r-a-y. DJPaul - you and I must have our dev machines configured to default to innodb.

#9 @boonebgorges
12 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 7187:

Force test install to use innodb.

Fixes #5038

Props r-a-y

Note: See TracTickets for help on using tickets.