Drupal's road map and perspective concerning Test Driven Development (TDD) and coding conventions

Being a freelance web developer, I am also working as a head developer for an Austrian company, and I brought in Drupal as CMS platform for one of the products, a web portal.

For the project at hand, we are also developing much non-Drupal business logic, and we are enthusiastic supportes of agile methologies, eXtreme Programming in this case. As those of you experienced with XP might know, TDD is an integral part of XP, and thus Unit Testing is very important in our everyday work.

I browsed drupal.org and found many posts concerning Unit Testing with Drupal, and I get the picture that Drupal will rely on TDD heavily (and rather natively) from the version 7.0 on.

One thing I don't understand yet is why Simpletest is the testing framework of choice for Drupal.

From my perspective (undoubtedly lacking information about the selection process), Simpletest suffers from serious setbacks.

Simpletest doesn't follow established good practices in the following fields:

• up to date technology — Simpletest is written in and targeted at PHP4 and thus won't play well in a strict, object oriented PHP5 environment (not to mention PHP6)
• naming conventions — Simpletest doesn't incorporate coding conventions that help simplify Unit Testing:
  • PHP5 autoloading — when you write 200+ tests for a large project, you'll cherish the __autoload() function of PHP5, which lets you automate the inclusion of dependent files.
    The PEAR coding standard of displaying the folder structure in the class name supports autoloading and requires, additionally, that your file name matches the last part of the class name (e.g. the class Path_To_ClassName can be automagically located in Path/To/ClassName.php)
  • namespaces — one pleasant side effect of the autoload coding convention is that it enforces namespaces. This means that classes following the formerly mentioned naming convention won't collide with other similar class names since their specific location in the project folder structure forms a part of the class name.

I am fully aware that Drupal itself deviates from the above practices. I understand that the Drupal concept of hooks asks for the use of undescores within function names—they are much easier to parse than camelCase.

For the sake of readability and maintainability I, personally, prefer camelCase to underscores in class and function names any time—in my own code I use underscores only for allcaps constants and for folder hierarchy distinction within class names.

But the battle between camelCasers and underscorers has gone on for decades, and we won't solve that matter here and now. So let's just declare this as a matter of preference.

the future of Simpletest in Drupal!?

Given the fact that Simpletest seems a little backwardish, I'd like to know why this framework has been chosen in favor of, say, PHPUnit (which is coded in PHP5 and plays well along strict OOP environment).

Will Simpletest be rehauled to follow common good practices? If so, when will that be?

What's the Drupal maintainers' opinion regarding the above points? What does Dries think about that?

Can the Drupal community influence what future versions of Simpletest will look like? Will there be any joint efforts of the respective developers?

Given the fact that Drupal 7 will support only PHP5, is there any chance that Drupal and Simpletest evolve more in the direction of PEAR naming conventions?

Questions, questions...

Best regards,
C.