testing

Drupal 7 testing: status update and next steps

Dries Buytaert's picture

The first version of Drupal's automated test framework was developed in 2004 by Moshe Weitzman. It started as a simple wrapper around the SimpleTest unit testing framework. Read full article »

Calculating test coverage

dhubler's picture

Here's how you can determine test coverage of your tests by generating a report like this one:
http://acquia.com/files/test-results/index.html

Step 1: Install xdebug php extension. On ubuntu I run

apt-get install php5-xdebug

Step 2: Checkout simpletest trunk anywhere on your disk. In this example I will choose /usr/local/simpletest

Step 3: Add simpletest to the php.ini loaded by apache. Read full article »

Keeps cron and RSS-feeds working while in offline mode or with protected directory

I have an Acquia dev site at my web host. I don't want it accessible to search engines and drop-in users yet, but most of the content will be available to anonymous users so I need to view it and test it as an anonymous user a great deal. So I can't rely on permissions to hide the site.

As an alternative, I've tried password-protecting the whole test site at the server/directory level, but then I found that I had trouble with features of my test site working such as cron and pulling in new content from RSS feeds. Read full article »

Drupal CLI utils

dhubler's picture

I put together a few scripts that I needed to configure and manage drupal from CLI.

They include the following scripts:
- Installer (install.php D6 & D7)
- Updater (update.php)
- Code Coverage (working example: http://acquia.com/latest-drupal-test-results)
- Unit Test Runner (run-tests.sh)
- Module enabler

and the following library code:
- CLI arg parser
- Drupal Web Form User Agent (uses php-curl)

additional points:
- Much of the code has unit tests (simpletest, php-mock-functions w/o runkit)
- Code was designed to be extended for custom purposes. Read full article »

Minnesota Search Sprint: Your top-five feature requests

Robert Douglass's picture

In the same way that the Internet itself would not have achieved greatness without the ability to search it easily and efficiently, Drupal's greatness will always be tied directly to the effectiveness of its core search solution. Improving core search for Drupal 7 will be no small task, however. The current implementation is both elegant but complex, robust yet inflexible. The seven coders participating in the Minnesota Search Sprint this weekend have a great challenge as well as a great opportunity. Here are some of the things we hope to achieve:

  • Identify the most important weaknesses in Drupal search and create a project plan for fixing them.
  • Identify the most important new features currently missing from Drupal search and clear the roadblocks for implementing them.
  • Increase the test coverage for Drupal search.
  • Increase general developer awareness and knowledge of search.

A large part of what we will be doing is evaluating and planning. Without a roadmap and common understanding of what search is to become, little progress will be made in the Drupal 7 development cycle. However, a coding sprint is all about code, and we'll be writing some of that, too. Specifically I'm hoping that we'll be able to fix one of the top-five bugs, increase search module's test coverage, and come up with a first attempt at one of the top-five new features.

That's a lot! No matter what we manage to code during the three days together, we'll walk away with a high level of agreement about our goals for the next months, and plenty of homework to do.

We'll post regular updates that you can follow on Planet Drupal, as well as in the search group, and we're all ears if you have suggestions or wishes. For anyone wanting to catch up on their search related reading, here are some links: Read full article »