A hook would be defined by each module/theme to execute a suite of tests on itself.

These tests could all be invoked on an administration page. Inter-module dependencies could be tested, new modifications could be tested...generally, anything that a module developer wants to test could be included. This would, IMO, make the community development process flow better as each developer could make sure his/her code doesn't break others' or in the presence of others'. It would allow you to instantly know when you have broken some major functionality of a given set of modules (or somebody else has broken yours).

I'm not interested in engaging in the battle over extreme programming or anything like that, just a means of testing module/theme functionality without having to click all over the place to do it. I would be content with the hook merely returning success or failure, but a testing framework may be useful for more detailed testing.

More information about test-driven development can be found at phpPatterns or at junit.org.

CommentFileSizeAuthor
#2 drupal_05.3 KBmoshe weitzman

Comments

moshe weitzman’s picture

This is a very smart proposal. I hope someone moves this forward. more relevant links:

- simpletest framework
- php unit testing intro

moshe weitzman’s picture

StatusFileSize
new5.3 KB

I've uploaded a 'simpletest' module to Contrib which provides a unit testing framework for drupal. Please give it a try and provide feedback. Especially try to write a test and see if the framework is useful. Here is the README:

Description
------------------
A framework for running unit tests in Drupal.

Status
------------------
One test has been written - 'user validation'. We need more.

Requirements
----------------

- Install the simpletest framework to a new directory called 'simpletest' right under Drupal root.
You can find it at http://www.lastcraft.com/simple_test.php

Install
-----------------------

- Copy this module package to your /modules directory
- Activate the simpletest.module
- Visit the admin/simpletest page

Simpletest hook
-----------------------

This module offers a new 'simpletest' hook. Modules implementing this hook should an array of paths which
point to test files. These paths should be relative to the /simpletest directory.

Writing Tests
-----------------------
Please write some tests. I'm a bit new at this and haven't decided on a worthy approach.

Author
---------------------

--------------------------------------------------------------------------------

Description
------------------
A framework for running unit tests in Drupal.

Status
------------------
No tests have been written. This framework should work though.

Requirements
----------------

- Install the simpletest framework to a new directory called 'simpletest' right under Drupal root.
You can find it at http://www.lastcraft.com/simple_test.php

Install
-----------------------

- Copy this module package to your /modules directory
- Activate the simpletest.module
- Visit the admin/simpletest page

Simpletest hook
-----------------------

This module offers a new 'simpletest' hook. Modules implementing this hook should an array of paths which
point to test files. These paths should be relative to the /simpletest directory.

Writing Tests
-----------------------
Please write some tests. I'm a bit new at this and haven't decided on a worthy approach.

morbus iff’s picture

I've very interested in this, and plan to make some efforts related to it. I am, however, cautious about where to store the actual test files. Traditionally, in Perl, they're usually in a directory called t/, with the running order of the tests defined by the file name (00_file.t runs before 10_url.t, for example). In the current Drupal file structure, there doesn't seem to be a proper place to put these, especially considering user contributed modules (for core, we could certainly create a root /t/ directory for all the core modules, but I feel their "distance" from the actual code in /modules/example.module would make it too easy to forget the need for constant pruning and addition - bad tests are worse than no tests at all).

One possible suggestion would be per-module directories, similar to flexinode (which has modules/flexinode/flexinode.module, and a bunch of .inc files). For example, modules/watchdog.module would now be modules/watchdog/watchdog.module, modules/watchdog/t/01_view.t, modules/watchdog/t/02_blah.t, and so forth. For watchdog, at least, this seems like over-organization, as there'd never be something BESIDES watchdog.module in /modules/watchdog/... so why create a whole 'nother subdirectory?

User-contribution wise, I'd like to think that modules/NAME/NAME.module, and modules/NAME/t/ are stronger, as it more closely follows the idea of a downloadable package (which would contain .sql files and READMEs and CHANGELOGs, etc.). The t/ would keep things more organized for contributors, and thus, the same organization scheme should be applied to core, even though it runs the risk of looking sparse and overthought.

Comments?

coreb’s picture

Project: Drupal core » SimpleTest
Version: x.y.z » 6.x-1.x-dev
Component: base system » Miscellaneous

Moving from x.y.z queue to 6.x-dev. Also moving this into simpletest's queue.

moshe weitzman’s picture

Status: Active » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)