Quality Assurance

I just released an install profile for D6 core that sets up a test site for trying out all the combinations of CCK date field configurations: CCK Date Testsite. I've discovered various bugs in Signup's handling of CCK date fields (and have been fleshing out bugs and limitations in DateAPI itself with KarenS's help). I was spending a lot of time just configuring a reasonable test site to try different combinations of CCK date field types (Date, Datestamp, vs. Datetime) and timezone handling (there are 5 different ways date fields can handle timezones). So, I quickly decided the time spent automating the test site would easily save me time in the long run. And, I hope this profile will be useful to other folks working with DateAPI and CCK date fields.

Here is an effort at documenting Drupal testing patterns from what's currently used in core tests. The objective is to promote reusability of standardized patterns throughout core and contributed tests.

// Catch - this looks good, but I think we should completely ignore stuff like getContent() which is used once per year and just focus one what 70% of basic tests will use - the API docs etc. are there, and linkable at the end, for everything else.

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.

Arizona State University's Applied Learning Technologies Institute (ASU alt^I) is seeking Drupal developers for immediate full-time, part-time and contract-based work. We have a variety of needs including theme development and maintenance, module development and maintenance, site administration / build-out, and testing / quality assurance. For all positions, contributors to the Drupal community are preferred, but not required.

Please send Jeff Beeman (jrbeeman on Drupal.org or jeff.beeman@asu.edu) a private message or email with any questions you may have about the posting.

Posting at: http://snipr.com/33u8s
The description at the posting page is a general one for Drupal developers - please see the details on specific positions we are looking to fill below and apply based on the description(s) you see here.

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).

<p>By: Robin Monks</p> 
<h1>Introduction</h1> 
<p>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!</p>

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 >

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.

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.

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.

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!

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.

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