In Drupal.org, for projects that are enabled, patches in the issue queues are passed to a test server, which essentially:

• creates a Drupal site
• copies, and installs the module from which the patch has been written
• applies the patch being tested
• runs a set of SimpleTest tests, which has been written by the maintainer of the project wrote for his own module, to verify the patch doesn't introduce any problem

Once the tests are done, the test server reports to Drupal.org the result, which is then shown in the issue where the patch is attached.

This is what essentially happens. I didn't mention all the details, such as:

• the Drupal site is created before to run every test
• the test server executes also its own tests to verify the created Drupal site is running correctly
• the test server periodically executes tests to verify it is running correctly
• the Drupal version, and the version of the module that needs to be installed are taken from the issue itself; if the issue is for version 6.x-1.0 of a module, then the test server creates a Drupal 6 site, and installs the version 6.x-1.0 of the module, to which it applies the patch found in the issue report

In Drupal.org, for projects that are enabled, patches in the issue queues are passed to a test server, which executes the following steps:

• It creates a Drupal site
• It copies, and installs the module for which the patch has been written
• It applies the patch being tested
• It runs a set of SimpleTest tests, which has been written by the maintainer of the project wrote for his own module, to verify the patch doesn't introduce any problem

Once the tests are done, the test server reports to Drupal.org the result, which is then shown in the issue where the patch is attached.

This is what essentially happens. I didn't mention all the details, such as:

• The Drupal site is created before to run every test
• The test server executes also its own tests to verify the created Drupal site is running correctly
• The test server periodically executes tests to verify it is running correctly
• The Drupal version, and the version of the module that needs to be installed are taken from the issue itself; if the issue is for version 6.x-1.0 of a module, then the test server creates a Drupal 6 site, and installs the version 6.x-1.0 of the module, to which it applies the patch found in the issue report

In Drupal.org, for projects that are enabled, patches in the issue queues are passed to a test server, which essentially:

• creates a Drupal site
• copy the module from which the patch has been written
• apply the patch
• run a set of SimpleTest tests, which has been written by the maintainer of the project wrote for his own module, to verify the patch doesn't introduce any problem

Once the tests are done, the test server reports to Drupal.org the result, which are then shown in the issue where the patch is attached.

This is what essentially happens. I didn't mention all the details, such as:

• the Drupal site is created before to run every test
• the test server executes also its own tests to verify the created Drupal site is running correctly
• the test server periodically executes tests to verify it is running correctly
• the Drupal version, and the version of the module that needs to be installed are taken from the issue itself; if the issue is for version 6.x-1.0 of a module, then the test server creates a Drupal 6 site, and then install the version 6.x-1.0 of the module, to which it applies the patch found in the issue report

In Drupal.org, for projects that are enabled, patches in the issue queues are passed to a test server, which essentially:

• creates a Drupal site
• copies, and installs the module from which the patch has been written
• applies the patch being tested
• runs a set of SimpleTest tests, which has been written by the maintainer of the project wrote for his own module, to verify the patch doesn't introduce any problem

Once the tests are done, the test server reports to Drupal.org the result, which is then shown in the issue where the patch is attached.

This is what essentially happens. I didn't mention all the details, such as:

• the Drupal site is created before to run every test
• the test server executes also its own tests to verify the created Drupal site is running correctly
• the test server periodically executes tests to verify it is running correctly
• the Drupal version, and the version of the module that needs to be installed are taken from the issue itself; if the issue is for version 6.x-1.0 of a module, then the test server creates a Drupal 6 site, and installs the version 6.x-1.0 of the module, to which it applies the patch found in the issue report