Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Skinr's tests should follow common/best practices in Drupal core.
This allows others to write tests for Skinr more easily and quicker.
I'll iterate over the changes in a comment.
Comment | File | Size | Author |
---|---|---|---|
skinr.tests_.0.patch | 8.7 KB | sun | |
Comments
Comment #1
sunSee #913086: Allow modules to provide default configuration for running tests
You cannot use the Testing installation profile, if the test relies on certain default configuration that is only setup by the Standard installation profile.
In this particular test case, all of the drupalCreateNode() calls should have bailed out with errors...? That is, because the testing profile does not setup any node types by default.
parent::setUp() installs Drupal core and also installs/enables the passed in modules. No need to do this manually (except for rare edge-cases).
If your test only needs one node, make it
$this->node
If you need multiple, either use
$this->nodes[] = ...
or when needing more explicit access, use
$this->article
$this->page
or
$this->article_node
$this->page_node
We commonly use the following properties:
$this->web_user: A user with regular permissions.
$this->admin_user: A user with administrative permissions.
Keep the assertion messages short and to the point.
Always use the constant when an ID refers to a constant.
Testing API functions in a DrupalWebTestCase directly from the test method is a special case:
Fundamentally, you need to understand that the test method is executed in the scope of the parent site (running the tests), but which is using the database of the child site (which is only executed when a test method performs a GET or POST request).
When a test is setup, the global $user is replaced with a stub user, which doesn't map to any user anywhere.
If you do a $this->drupalCreateUser(), then a new user record is created in the child site.
If you do a $this->drupalLogin(), then the internal browser of SimpleTest is used to log in to the child site. This means you have a user session in the child site. But NOT in the parent site (where the test method is executed).
The user session affects all requests against the child site; i.e., all $this->drupalGet() and $this->drupalPost().
However, the global $user in the parent site is not affected. You need to replace it manually.
Likewise, clearing caches in the client site does not clear caches in the parent site. Same applies to setting or deleting variables, etc.pp.
Not sure whether this is documented somewhere on drupal.org, but it definitely should be. Feel free to create a handbook page out of this, if you want.
In 99% of all cases, \n in a string can be replaced with a real linefeed. Also doesn't need double-quotes.
Comment #2
moonray CreditAttribution: moonray commentedThanks for this @sun. Let me know whenever you come across other non-standard drupal coding issues. :)
Comment #3
sunThis is probably RTBC. However, note that I've only "fixed" this particular test case.
Comment #4
moonray CreditAttribution: moonray commentedCommitted, but leaving open. Some more cleanup is required for Skinr UI's tests.