I'm new to simpletest 2.x and found out from a D7 comment that $this->drupalVariableSet() should be upgraded with variable_set(). As simpletest duplicates all db tables with simpletest prefix all the settings are saved in this temp tables. Is this correct?

I tried this, but it mess up my installation as this does not turn back the prior settings after the test is completed. In 1.x I was able to run all tests without any changes on the installation. My feeling is that the DB table switch isn't working... sounds like a bug to me.

Comments

boombatower’s picture

boombatower commented
Status: Active » Postponed (maintainer needs more info)

I'm not sure how that would work.

Please set simpletest_clear_results to FALSE and if you see a set of tables for each testMethod() then it is working fine.

This would hose contrib tests, so I'm not sure it is broken.

Otherwise you are correct in changing to variable_set.

hass’s picture

hass commented

Only that I understand this - the upgrade path for $this->drupalVariableSet() is to change to variable_set()? This is correct?

It is the expected behaviour that my site gets cluttered by the tests and the values set while running the tests?

Aside it would be ultra helpful if you could write a handbook page How to upgrade from 1.x tests to 2.x tests like we have handbook pages for modules/themes upgrades. Thank you!

hass’s picture

hass commented

Only that this is not a misunderstanding - simpletest_clear_results (#291750: SimpleTest: Remove test results after displayed) clears the simpletest test result tables, but doesn't reset all variables back to time before I executed my test, isn't it?

How can my variables overridden while running tests automatically roll back to the original values before I started the tests?

hass’s picture

hass commented
Category: support » bug
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

@boombatower: Can you confirm the following logic if simpletest works or better should work this way?

0. User selects to run a modules test.
1. drupal_web_test_case executes setUp() and copies the $db_prefix name to a $this->db_prefix_original value
2. Now $db_prefix is changed to 'simpletest' . mt_rand(1000, 1000000).
3. Then standard module install process starts and creates all module tables with simpletest prefix
4. Now the selected simpletest .test files are running on the simpletest prefixed tables and values are written there - not into the production database.
5. Then the simpletests are finished.
6. drupal_web_test_case executes tearDown() and drop all temp tables prefixed with simpletest, cleans up the simpletest environment created in setUp() or while running the tests, etc.
8. Now global $db_prefix changes back from 'simpletest' . mt_rand(1000, 1000000) to $this->db_prefix_original

With this logic a site wouldn't get cluttered by variable_set() in the .test scripts, but this is today the case. I think the DB table switch from standard production tables to the random simpletest tables is not working.

hass’s picture

hass commented

The dump in http://drupal.org/node/334554#comment-1116879 shows that #4 seems to be correct, but is not working as expected. This bug could be related to #334554: SimpleTest: Prevent endless loop and upper timeout during request, but I cannot say for sure.

boombatower’s picture

boombatower commented

I'm really not sure what to say. You seem to have the impression that this module doesn't work and I know about it. Like I've said before this module works fine for others.

Have you check to make sure that the USER_AGENT variable works in your environment? Have you followed the INSTALL.txt instructions to place the check in the settings.php.

The workflow you described in #4 is correct and this module functions that way on my machine and others....I'm not sure why it doesn't on your. Other than checking the things I mentioned...and debugging yourself...I'm not sure how to help as I cannot reproduce any of the things you have described.

As for the update path...anyone can feel free to write that...there is a number of documents on how to write in the new style....should be fairly straight forward to read them and convert.

From my understanding there are very few modules that even have tests written in 1.x format so writing the document is very low on my priority list. Feel free.

From what I can tell most of the upgrade issues you are having are related to these bugs...

hass’s picture

hass commented

I assure you I have read and followed the INSTALL.TXT more than once.

I know this module doesn't work well in all cases - this is not an impression! It doesn't have an upgrade path what is OK for D7 until this becomes beta1, but not for a D6 nor a D5 module and much more bugs!

See the mysql dump any you might get an idea what could be wrong in the module and also let me say that I wasn't able to see a real batch process what may cause the timeout and therefore the 500 error. A batch process is only shown if I select multiple tests, but this doesn't prevent the processes from running into a time out within a test or install process.

IIS also have a HTTP_USER_AGENT, but keep in mind I'm also able to repro the above in a XAMPP environment.

hass’s picture

hass commented

Also reproduced the cluttering on D7 with google analytics test.

boombatower’s picture

boombatower commented
Title: variable_set() mess up installation » SimpleTest: variable_set() mess up installation
Project: SimpleTest » Drupal core
Version: 6.x-2.5 » 7.x-dev
Component: Code » simpletest.module

Then this needs to be discussed in core.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Fixed

I don't think this applies anymore. I use variable_set all the time and it is used in core tests too, and it does not affect the non-testing database. Since there has been no report back from hass since November and we've had multiple backports since then, I am marking this as fixed.

hass’s picture

hass commented

I haven't retested this again...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

hass’s picture

hass commented

The bad thing is that there was no progress in this case and it's not clear what patch may have fixed it, but it seems to be fixed. I've only done a quick test... cannot say for sure.

mdshields’s picture

mdshields commented

SO, what is the word? does SimpleTest work with Drupal 7 or not?

If nobody can have an answer for whether to use variable_set or drupalVariableSet, then that just means SimpleTest wasn't designed for the Drupal community? so, we just test core features only and not any modules? Still trying to follow, we have variables in our modules so that we don't have to hard code anything, but if we use SimpleTest, then we do have to hard code?

what was the problem with drupalVariableSet anyways?