Exception: The specified database connection is not defined: default

We'll see if this is still an issue after the tests actually start working. My suspicion is that's either an error related to prefixing that is just a plain ol' DBTNG problem, or could be an error that DBTNG shows when a test throws a fatal error (which the test in question was doing at that time, I believe).

So, marking postponed until we know more.

My guess actually having looked at 0 code from the dbtng module is that its because I just set $db_url as a string not an array. Actually I can probably test this by making it an array. Will report back...

#879704: Kill the account status module completely, decide removing first?

This actually happens at the end of every test, sorry. That's just the test I was running to test the other issue and is an artifact of that. Updated title to reflect this.

So, this may very well be a simpletest issue but since its so hard to get fixes in dbtng might just have to work around it. Also, this is actually really important because this exception is a symptom of a bigger problem.

It boils down to this, dbtng_init() sets up the $databases global that's used by the rest of the library for connecting to the database. Since its never called when running simpletests, those tests will always throw this exception as soon as we try to use dbtng. This isn't caught and throws us out of the testing loop. This means any further tests are also not run.

I'm pretty sure this is totally wrong but I put

    if (empty($databases)) {
      dbtng_init(); // force something into databases...
    }

directly after global $databases; in parseConnectionInfo.
</psuedopatch>

Moving this to dbtng since mikey_p said he could make a patch.

Finally I could run a test(#914392-11: While testing, default prefix is used instead of simpletest prefix by dbtng-driven queries ) with dbtng without versioncontrol! (and I could never reproduce the exception mentioned here :-/)

But I am receiving an array on $databases global variable with the db info, but not with the right prefix, that's why I had to remove the conditional.

attached as patch to help test.

But this problem seems to be at simpletest, why simpletest module is not calling hook_init()?

I want to share a conversation I had some minutes ago at #drupal-contribute:

marvil07 is hook_boot called at simpletest tests?
marvil07 s/hook_boot/hook_init/
carlos8f marvil07: that's a good question, i don't think hook_init() fires in the test method, but it does inside drupalGet(), etc.
marvil07 carlos8f: that would make sense if simpletest does not bootstrap(which AFAI could read doesn't)
carlos8f marvil07: if you need to test a hook, the best thing is to trigger full requests with drupalGet() etc., and use a test module. that way you ensure that all the normal hooks run, i.e. hook_init
carlos8f marvil07: so no, hook_init() isn't meant to be called for you in the test method
marvil07 carlos8f: thanks for the feedback, my problem is that I am dealing with a module(versioncontrol) that depend on another module that use hook_init(dbtng), and I need to prove CRUD is working fine without the UI
carlos8f marvil07: if dbtng depends on init, you would be suited to create a test module and test it inside a menu item, triggered with drupalGet or post.
marvil07 carlos8f: yep, or manually call its hook_init :-p
carlos8f marvil07: i wouldn't recommend that :)
marvil07 carlos8f: great, I think now is clear :-), are you ok if I copy this lines to the related issue?
carlos8f marvil07: no problem

Another solution could be move the code at hook_init() to hook_boot() and ask simpletest module to call manually hook_boot() at DrupalWebTestCase::setUp().

Actually, I'm thinking dbtng might have a case for providing its own test type. I don't agree that manually calling dbtng_init is a bad idea in the context of dbtng testing but I do agree that requiring tests do it is less than ideal.

I'm not sure why we can't just lazy load like this though. It means dbtng is more resilient to different uses.

Also, I think the if (empty($databases)) { is a good thing as it keeps $databases from always being rebuilt.

// make sure we have the right databases
// aka make simpletest know about the right prefix

I think this is actually incorrect. It makes sure dbtng knows where the database is and recover in situations where dbtng_init() has not been called like in tests. Custom bootstraps or calls in hook_boot are other places that could have this problem.

I think this is the correct conclusion. neclimdul is right that it's just an issue of hook_init not being called. When I first ported dbtng I figured that was the logical place to put the code to parse the D6 connection string, and that has generally been true, since I was trying to patch the actual files from D7 as little as possible, and it's worked fine most of the time until now. I'll add this check in to make sure that the $database connection info is re-parsed at the last available moment before DBTNG tries to make a connection.

Ok, since calling hook_init() manually on test seems like a good idea for neclimdul and me, I just have done that from a DBTNGTestCase base class, where I am also removing the connection after each test to avoid problems with prefixes. See #914392-18: While testing, default prefix is used instead of simpletest prefix by dbtng-driven queries for the patch.

Not really sure if this issue this original disappears applying that patch, @neclimdul: can you confirm that?

pulling forward to sprint 4

There is no more hook_init, and the database connection info is parsed when needed inside Database::parseConnectionInfo().