Setup optional modules fails -> patch review fails

I believe that the current workaround for this is to create a 'hidden' test sub-module which does depend on token, and (optionally?) move the related feature tests there ... but the dependencies will then need to be rebuilt, which a few projects have been having troubles with. Dependencies are supposed to be rebuilt every 12 hours, but may only be happening upon creation of a release. Since creating a release to 'test' a workaround isn't ideal, if the dependencies aren't rebuilt 12 hours after the commit introducing the submodule, post back when ready and we can try triggering a manual dependency rebuild.

1. Create a sub-module in your project with a hard dependency on token.
2. Move the token-specific tests into the the sub-module.
3. Commit to repo.
4. If the test isn't passing 12 hours later (i.e. dependencies haven't been rebuilt), post here asking to have dependencies rebuilt manually.

The way to get modules downloaded is through dependencies in info files. They are calculated recursively, as they would need to be.

The fact is, your module (in its tests) has a dependency on token. That's the fact. So you can either change the test, or add a dependency. The simple workaround is to create a "mock module" in the tests subdirectory that has a dependency on token.

Sorry, but I do not need a submodule in the GA module. Why should I add one?

Your initial post was "How can I solve this issue without excluding the tests?"

Question asked, and answered.

If you don't like the answer, then let me provide an alternate one ... Code the feature (they way you want it to work) for the testbot, because today, what you are asking for does not exist. Having the bot parse names from the test files is a change in functionality, and therefore a 'feature request', not a bug.

That, I can certainly agree to. :)

I really have no idea how this could be implemented.

Note that module_enable() might be called on any string, which could be a part of some undetermined project.

The testbot has to figure out how to check out the projects that are needed. It does that by using the dependency information which is explicitly given.

Even parsing all the code of Drupal + all modules would not be adequate to solve this problem, since the module we want to enable may have dependencies itself, and it may not be a part of a project by the same name.

x-post

The problem is that only gives us the first level of dependencies. For a project that depends on views, the tests will still fail because of the unwritten dependency that views has on ctools. Forcing module authors to specify the complete dependency chain would be laborous and unmanagable.

Alternatively, if you wanted to recursively parse and calculate these after each individual checkout, it would require a complete refactoring of the PIFR process.

You know, I forgot - the correct and excellent answer for this is test_dependencies, as proposed in #698932: "test_dependencies" for dependencies / integration tests - it would allow listing in the info file modules that are not required for the module to run, but which could be used by it for tests or whatever.

And this is now deployed, so you can use test_dependencies[] = to solve this problem. http://qa.drupal.org/node/198

Please note that:

1. Dependencies are not calculated on patches, ever.
2. Dependencies are generated at release generation time. That means for a dev release, every 12 hours if a commit has happened.
3. We can rebuild dependencies manually on request.

http://drupal.org/project/testbot has some FAQs

Marking fixed until further notice.

@hass, #20: The dependency rules should be exactly the ones for core, as documented at http://drupal.org/node/542202#dependencies. They are copied from Drupal 7's work. Since this is currently a D6 module...

@hass, #25, please open a core issue or a documentation issue and reference it here. This implementation is just the Drupal implementation.

On #26, please figure out a way to calculate dependencies on patches and provide a patch to PIFT that would do it. But don't break anything.

@hass, We just used the D7 code. I don't know the history. You could do a git blame on that section of code to find out what issue changed it and see if there were API changes.