No tests run - Call to undefined function install_no_profile_error()

I am also getting this issue....

I am running a vanilla version of acquia-drupal-1.2.1, on a MAMP setup.

Error message:

An error occurred. /acquia-drupal-1.2.1_test/batch?id=3&op=do
Fatal error: Call to undefined function install_no_profile_error() in /Users/lukehamilton/Sites/acquia-drupal-1.2.1_test/includes/install.inc on line 277

I just tested this on vanilla drupal-6.9/MAMP and am not getting this issue.

Looks like configuration issue?

In my testing Simpletest is failing if the profile/default profile is not present. If the profile/default profile is added to a site that has only a different install profile simpletest seems to function.

#4: yea it expects the default, as all the tests need a common profile.

Sounds answered to me...

Reopening... I don't understand why Simpletest needs to rely on any profile other than the one used to install the site... Or any profile at all for that matter. What is it using the profile for?

On a further investigation, it uses the default profile when creating a new test environment (DB schema) for running a test suite. It uses the list of modules declared in the default profile as a barebones Drupal install to do these tests, which I guess is fair enough (although I wish it wouldn't leave its simpletest_ tables around in the DB after it fails, it needs a cleanup cron or something...)

I think that if the default profile is not available, it should fall back to using whatever profile was used to install the site, as it can be pretty sure that that profile would include the same set of essential modules as the default one, otherwise Drupal wouldn't be running.

I've provided a patch that does this for those that are interested in not having to reinstate the default profile. It will display a warning that SimpleTest may not function properly without the default profile (although it worked fine for me on my profile, just degraded performance since my profile installs a lot of extra stuff that it didn't need).

There is a "clean environment" button. When tests crashes it leaves tables as there is no alternative...cron doesn't work since we allow running of the tests in multiple process...and the tables should never be left except during development...and thus "THE BUTTON". :)

This subject needs to be discussed in D7 and backported as D6-2.x is a pure backport. I am working on the #323477: Increase simpletest speed by running on a simplified profile patch which would allow you to test on a live data-set for configuration/workflow testing. Not exactly the same, but along those lines.

This issue has already been brought up: #279515: setting an installation profile for a test doesn't run hook_install_tasks(). Please further the discussion there.

As I'm sure you noticed on #400296: Make simpletest_get_like_tables() work in MySQL and PostgreSQL, I've now found the button, and have now made it work on Postgres :)

I was unaware of this other discussion. Thanks for that. I can't wait to get my hands on D7 property, it seems to do a lot of things better...

The patch in #9 worked for me. I am running an instance of Acquia Drupal, and all tests fail without this patch.

Thanks for your work on this module, boombatower, and I am psyched that SimpletTest is in D7 core. Very important step for the Drupal community.

The same problem on Pressflow (6.16.77)

This error may occur when a person is using the Acquia stack. The stack doesn't seem to come with profile/default, so one will need to copy and paste it from a clean drupal download to the profile folder.

Does the same hold true for pressflow? If so then I am closing this issue as this is not something the testframework needs to deal with, but that the frameworks need to decide if they choose to support testing.

Re-rolled the patch for SimpleTest 2.10

Tests just hang without errors.

I installed, patched, copied default profile from a standard drupal version (non acquia).
Clicked the "clean environment" button.
Cleared cache.

I'm not running my own tests, im using the Block module tests, because they seem very simple I assume they work normaly. The progress bar shows and that's it. It never completes. There's no errors. I looked in the logs.

Any hints ? ;)

thanks.

Here's a version of the patch that applies to pressflow 6 (and some whitespace cleanup).

I'm having a few problems with the patch in #20. This is a screenshot, using vanilla pressflow 6:

https://www.evernote.com/shard/s57/sh/082644a9-d6a7-40fe-87f6-0c02f935d9...

That's the standard block test that comes with pressflow's simpletest module. I've had similar problems with other tests on contrib modules too using a far more complex install (I think you know the one I'm talking about ;) ). It seems the setUp() method throws exceptions (warnings really) on every test, though the tests continue ok.

Seems like the issues are these:

+++ b/modules/simpletest/drupal_web_test_case.phpundefined
@@ -1122,7 +1122,19 @@ class DrupalWebTestCase extends DrupalTestCase {
+      $modules = array_unique(array_merge(drupal_verify_profile('default', 'en'), $args));

$args isn't set, and causes an error on array_merge.

+++ b/modules/simpletest/drupal_web_test_case.phpundefined
@@ -1122,7 +1122,19 @@ class DrupalWebTestCase extends DrupalTestCase {
+      $modules = array_unique(array_merge(drupal_verify_profile($profile_in_use, 'en'), $args));

Same issue with $args here.

+++ b/modules/simpletest/drupal_web_test_case.phpundefined
@@ -1144,7 +1156,7 @@ class DrupalWebTestCase extends DrupalTestCase {
+    module_invoke($profile_in_use, 'profile_tasks', $task, '');

module_invoke ends up passing $task as a value - I think we'd need to call {$profile}_profile_tasks without using the call_user_func_array in module_invoke.

I'll have a play around with modifying this and see where I end up ...

Attaching a version of #19 that removes the issues I mentioned.

+++ b/modules/simpletest/drupal_web_test_case.phpundefined
@@ -1122,7 +1122,19 @@ class DrupalWebTestCase extends DrupalTestCase {
+    drupal_install_modules(drupal_verify_profile($profile_in_use, 'en'));

Looking at this again, should the argument have been $modules here?

Version 6.x is no longer supported due to Drupal 6 End of Life.