Test namespace conflict

your patch tests are postponed because the branch doesn't test successfully. qa.drupal.org/pifr/test/54698

No, the *branch* (the checked-in code) does not pass testing, so it doesn't make any sense to test the patch. You can work with the maintainer to solve the branch tests failing.

I have *just* deployed new code on drupal.org that will allow maintainers to see branch status right on drupal.org, but it has to be configured still. There the maintainer be able to request a branch retest and such. This will be enabled shortly.

Right now, you can go to your issue and follow the view details link over to qa.drupal.org. There you can click on the Branch Profile 2 - 7.x-1.x link to see what the testing results were for Profile 7.x-1.x (the branch, checked in). Then you can work with the maintainer to solve the problems there, check in new code, and go forward.

I've just requested a retest on Profile 7.x-1.x (http://qa.drupal.org/pifr/test/54698) in case it might pass now.

If the branch being tested does not pass without the patch, then the tests *with* the patch will most likely fail as well.

Because it's not starting from a known good state, the testbot can not determine whether the failure is due to the code in your patch, or an existing problem with your module ... and since it can not reliably determine if the patch should pass or fail, it refuses to actually test it.

To solve this, you need to get the code in the repository to a point where it passes all tests.

If you go to http://qa.drupal.org/pifr/test/54698, you can see which tests are failing. Anything in red or yellow needs to be addressed before you will be able to test individual patches successfully.

Each commit to your code will cause the code in the repository to be re-run (e.g. what we refer to as a 'branch test'); so there isn't anything special that you need to do other than fix the problems which are causing the existing tests to fail ... once the branch runs clean without any patches, then the system will (I believe) automatically start testing all of the postponed tests within your queue.

Hope this helps ... let me know if you could use further clarification!

And... drum roll... @claudiu.cristea you can now see branch test results on the "Automated testing" tab of any project... http://drupal.org/node/623208/testing-status

It's all jthorson

jthorson++

Have you run the tests manually? If you look at the log you'll see the description of why there was a total failure (which isn't usually the case). It looks to me like it's not possible to run Profile2's tests at this time.

[07:15:33] Command [/usr/bin/php ./scripts/run-tests.sh --concurrency 8 --php /usr/bin/php --url 'http://drupaltestbot699-mysql/checkout' --file sites/default/modules/profile2/profile2.test,sites/default/modules/og/og_migrate/og_migrate.test,sites/default/modules/og/og_access/og_access.test,sites/default/modules/og/og.test,sites/default/modules/og/tests/upgrade/og.upgrade.test --clean 2>&1] succeeded
  Duration: 1 seconds
  Directory: [/var/lib/drupaltestbot/sites/default/files/checkout]
  Completion status: [0]
  Output: [PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'ProfileCRUDTestCase-class' for key 'PRIMARY': INSERT INTO {registry} (name, type, filename, module, weight) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array
(
    [:db_insert_placeholder_0] => ProfileCRUDTestCase
    [:db_insert_placeholder_1] => class
    [:db_insert_placeholder_2] => sites/default/modules/profile2/profile2.test
    [:db_insert_placeholder_3] => profile2
    [:db_insert_placeholder_4] => 0
)
 in _registry_parse_file() (line 179 of /var/lib/drupaltestbot/sites/default/files/checkout/includes/registry.inc).].

If you look in http://qa.drupal.org/pifr/test/54698 you'll see the various dependencies that were checked out (it tries for the most recent stable release). Try checking those out, just like it did, and see what results you get.

If that doesn't help, we can capture the result of a test run and then run manually on the testbot.

That's definitely a non-standard failure ... I've triggered a retest to see if it happens again (versus it being some weird one-time event), since the previous test attempt had failed 'properly'.

The testing infrastructure is not intended to test dependencies as well, but that is something that we had seen occuring during some earlier testing. I believe the fix for this was included in the new 6.x-2.7 release.

However, that doesn't explain the current failures ... which was even more spectacular on the retest (no test review log?)

It's failing to install; it looks to me like with the implied dependencies there are two tests of the same name.

When things settle down on the testbots we'll force a retest and then take the testbot offline so we can run a manual test.

Well, I'm baffled. Whenever you try to enable profile2, or even clear the cache, you get the below. And there is nothing in the registry table that matches 'Profile%'. Even registry_rebuild can't get past that.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'ProfileCRUDTestCase-class' for key 'PRIMARY': INSERT INTO {registry} (name, type, filename, module, weight) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array
(
    [:db_insert_placeholder_0] => ProfileCRUDTestCase
    [:db_insert_placeholder_1] => class
    [:db_insert_placeholder_2] => sites/default/modules/profile2/profile2.test
    [:db_insert_placeholder_3] => profile2
    [:db_insert_placeholder_4] => 0
)
 in _registry_parse_file() (line 179 of /var/lib/drupaltestbot/sites/default/files/checkout/includes/registry.inc).

Here's the problem: #777168: Notice: Undefined property: stdClass::$uid in profile_user_presave() (http://drupalcode.org/project/drupal.git/775d4d) introduced a core test of the same name.

Probably time to namespace those tests better. If you run against latest D7, you'll see this fail.

But, of course, not fixed :-)

Sadly, the fix has to be done before the patch can be tested.

This patch will need to be committed before any profile2 patches will be testable .. including this one ...

So since the testbot isn't going to validate the test namechange patch, I'll go out on a limb and say that it's ready based on a visual review. :)

It turns out that as as result of this, any module requiring Profile2 in its .info will also fail testing-- it never gets past Profile2 testing!

This patch looks good to me too! Let's get it committed.

RTBC.

Hmmm ... so we're still running full tests on dependent modules? Can you note that and link to an example in the 'Testbot' project?

ouch.. Thanks, committed.

Committed and pushed, minus the whitespace change.

And the branch tests pass now: http://drupal.org/node/623208/testing-status

Yay! Thanks, @claudiu.cristea