|Status:||closed (won't fix)|
Since the general cleanup of SimpleTest is just about finished I figured we could discuss the new task of unit testing. We still need the functional tests completed and go through and clean-up old tests, but the API changes and coding standards are just about done.
I will layout what my current understand of the plan from conversations on IRC so that we can formal document the discussion and ensure that everyone is on the same page.
There will be one class (test case) per file and one file per core file. This will provide a simple convention that makes sense for unit testing.
block.admin.inc -> block.admin.inc.test
block.module -> block.module.test
The classes will then be named in a similar fashion.
block.admin.inc -> BlockAdminIncTestCase
block.module -> BlockModuleTestCase
With the large number of unit tests a better way of grouping tests needs to be created.
Each test method should be related to the function it tests in a 1-to-1 relationship.
db_query -> test_db_query
_db_query -> test__db_query <- double underscore
To perform unit testing each function needs to be isolated from all other functions. To do this all "sub calls" to other drupal functions need be located and each drupal function needs to be overridden to return a static value. The current plan is to use runkit.
There are several things that need to be figured in out for this to work.
- At what scope should functions be overridden? - Globally, per file, per function, or use a default and deviate where necessary?
- If functions are not overridden globally should they be reset after the current scope exits?
- How should functions be overridden? Using
runkit_function_[add|redefine]? Or define the function in the file and use
- If functions are overridden per test function how can we use
runkit_function_renamesince they will conflict when defined?
I have created a module that automates the majority of the above mentioned that is possible to automate. I will update it once a convention has been decided on. I will then generate all the test cases and commit them. This will provide a consistent base for tests to be filled in.