This group will soon be merged into the http://groups.drupal.org/testing-qa group. That group used to be the unit-testing group but was expanded to include QA in general making this group less improtant. So...

If you haven't already, subscribe to http://groups.drupal.org/testing-qa

Yay for the removal and abolishment of redundancy and repetition! Yay for Webchick and Angela Byron!

If you're looking for current status, look at the most recent comment

Since we've still got core test failures, and no automated patch testing, I thought it'd be worth doing a snapshot of tests that pass week by week (or more frequently if there's lots of commits). This allows us to keep a historical overview of where bugs have been introduced into either core code, simpletest.module or tests themselves. It should also hopefully help to reduce duplicate issues about broken tests (since a test failure can be down to any one of those conditions).

By: Robin Monks

Introduction

Drupal is community. It’s a community of visionaries that make Drupal what it is, we all want to see Drupal be more powerful, more flexible, and just plain better than the competition!

Hold on, hear me out :o) We're a really focused and strong (and almost too commercial) community, and we really have put our focus on features and output, and we've lacked a lot when it's come to making it all work correctly in every possible case.

That's where quality testing comes in. I've been thinking about Drupal's quality assurance process for a couple years now, but in the last few months it's really come to a head for me. My personal "dam-breaking" moment came when the Batch API in Drupal 6 prevented install, and other tasks depending on the API from running automatically, or in text based browsers, or in browsers were people have been privacy conscious and disabled JS and Meta refresh tags.

Without proper quality trails this will continue to happen. And here's another point I'd like to make:

Continue reading and comment at DrupalFiles >

Background and Purpose
After the SimpleTest session Wednesday morning I talked with sethcohn about some possible solutions to some of the issues that are being faced with full scale implementation of the unit test coverage. Some of the ideas are specific to the SimpleTest framework, but much could be applied to other testing frameworks. According to chx it sounds like the SimpleTest framework is going to be used which makes this information especially relevent.

To start off the biggest unknown currently is how to go about implementing "function unit testing" (which I beleive is the term). In other words calling an individual function with different arguements and checking the results against the know correct output. Until now this has been virtually untested and, to my knowledge, not really thought about at all. Instead "functional" testing has been worked on (as I was apart of).

We received, by show of hands, a considerable number of people who claim to be interested in contributing to the testing challenge, as introduced by Dries in his keynote. If anywhere near the number of people that raised their hands contribute, it could create a very chaotic situation and put a lot of pressure on the SimpleTest maintainer(s). In an attempt to address this I have compiled some ideas and thoughts.

So I am writing a new CCK field and because I practice test driven development I find myself testing that I have implemented the CCK api hooks correctly. This basically means testing against the interface. Usually in a pure OO class orientated world for unit testing we would use a mock library (e.g.

It stands to reason that the tests in simpletest/tests will be the ones that people will use to base their own tests. These tests were written by at least 5-6 different people, and it shows. As a result, it's really confusing for a new developer to get a sense of what your own module's SimpleTest integration ought to look like.

So let's create a template and some guidelines for what simpletests ought to look like, and then make a GHOP task for formatting all of the existing tests in this way. This is a wiki page, so please edit and improve.

<?php
// $Id$

/**
 * Brief description of test case here.
 */
class FileNameTest extends DrupalTestCase {

  /**
   * Drupal SimpleTest method: return metadata about the test.
   */
  function get_info() {
    return array(
      'name' => t('A few words describing tests.'),
      'desc' => t('A complete sentence describing an overview of the tests included in the file.'),
      'group' => t('Unique grouping name'),
    );
  }

  /**
   * SimpleTest core method: code run before each and every test method.
   *
   * Optional. You only need this if you have setup tasks.
   */
  function setUp() {
    parent::setUp();

    // Setup tasks go here.
  }

  /**
   * SimpleTest core method: code run after each and every test method.
   *
   * Optional. You only need this if you have teardown tasks.
   */
  function tearDown() {
    // Teardown tasks go here.

    parent::tearDown();
  }

  /**
   * One-sentence description of what test entails.
   */
  function testExampleThing() {
    // Assertions, etc. go here.
  }

  /**
   * One-sentence description of what test entails.
   */
  function testNextExampleThing() {
    // Assertions, etc. go here.
  }

  // Can have many more testFoo functions.
}

Questions:

1. What should be the file naming convention? module_name_verb describing task.test seems to be common; for example, user_access.test, and page_view.test. Is that ok?
2. When does it make sense to split a module up into multiple .test files, vs. one big one that tests everything? What's the guideline for this?

Hello, since the QA BOF at DrupalCon Barcelona we have been developing an automated patch and unit testing system for Drupal core. We aren't quite ready to launch it live, but wanted to give QA enthusiasts an early look at what we are doing. Please review http://testing.drupal.org and file issues.

Hi everyone. I've written an article introducing unit testing and the Simpletest module on Lullabot.com. Hope you enjoy it!

There will be a discussion about Drupal testing and how to make it happen at Drupalcon Barcelona BOF room 1.
Sorry for such a short notice.

What kinds of things should the QA team work towards?

What kinds of tools might we need to get there?

Goals I can think of are:

1. Ensuring that "active" issues are high quality (non duplicate, full information to reproduce, etc)
2. Providing regression testing prior to major releases
3. Providing a way for "non-coders" to get involved in the project
4. {your goal here}

Tools to investigate to support some or all of these goals:

SimpleTest, CoScripter, Selenium, DAST, SimpleTest Automation Framework