Steps:

- create a Features module with a single flag in it.
- then enable the Features module
- then run any SimpleTest case that inherits from DrupalWebTestCase and enables the Flag module. Set it to die() half way through to get the test run tables left behind.
- then look at the flags table for that run - you'll see it has the flag from your Features module in it.

This shouldn't be the case - that data shouldn't be in the test database. Other forms of exportable don't do this; e.g. a Features module storing content type definitions will not cause those content types to appear in a test run database.

Comments

quicksketch’s picture

quicksketch
he/him
commented

Flag behaves differently than other modules that provide exports. Because Flags are intended to be "partially locked", such as locking the name or flag type but allowing the user to change the text. It's true that Flag behaves differently than other exportables, but this is the intended functionality of Flag module.

joachim’s picture

joachim commented
Status: Active » Closed (works as designed)

Closing this.

> Flag behaves differently than other modules that provide exports. Because Flags are intended to be "partially locked", such as locking the name or flag type but allowing the user to change the text.

This is very useful to know! I was wondering why flag doesn't use CTools for its exportables.