Last updated June 12, 2014. Created on July 24, 2012.
Edited by widukind, Sylvain Lecoy. Log in to edit this page.

Test-infected development

Here is a very nice article written by Adobe on their Cairngorm 3 framework:

Test-infected developers never write their tests days after their code. Test-infected developers want to write tests, because that's the way they think about software development. They don't want to think otherwise. Test-infected developers never have excuses not to test. They are never too busy to test, their environments never take up too much time to create test data, and their customer never complain that testing is too expensive because it takes too much time.

If it is difficult to create an environment of test infected developers,

  • analyze the design of the application for testable code, prevent repetitive and over-specified tests, keep tests small, easy and close to the way objects are used in production.
  • don't attempt to test every single line of code in your application. Realize that functional tests have a role. Focus your unit tests to test behaviour and not structure and wiring.
  • ensure libraries, frameworks, API projects, any other code that is shared by multiple developers achieve the highest coverage and quality of tests.
  • keep quality of test code as high as application code. Maintain tests with refactorings but realize that it's sometimes easier to throw away and rewrite tests as it's sometimes easier to throw away and rewrite code.

http://sourceforge.net/adobe/cairngorm/wiki/BestPracticesAgileUnitTestin...

Raison d'etre of the API

If you don't know the testing framework used by Drupal or you are just curious about how it is implemented, you should first have a read at SimpleTest. This module is part of drupal core since 7.x release and is integrated through http://qa.drupal.org process. Each patch that you submit in the issue queue get fetched and approximatively 30.000 sql tests are run to ensure your patch is complient.

The Blizzard Community Platform API, as a framework module, is build with a very solid test suite. You can have more information on the Automated Test tab of the project. When developing upon this library, whether you are introducing changes or not, you should always ensure the full test suite passes green before releasing your product. This will ensure your module wont break any existing feature.

It is considered as a good practise to provide tests, and more importantly for an API module such as this one. The raison d'etre for this project is to provide an extensible set of platform quality API for the Drupal community to build upon. High-quality APIs take a lot of hard work to create. Thus it is essential that each components have a specification document, a test suite, an implementation and a support promise.

Run the test suite

You can either run the test suite from qa.drupal.org via the Automated Test tab of the project, either run the test suite locally. To do, go to your modules admin page and enable SimpleTest. Once enabled, go to the configuration pages, enter Testing.

Each component has its own test suite, they are grouped by name: WoW Character, WoW Realm, WoW Guild, and so on. The tests are isolated enough that if you work on a specific component, running exclusively the test suite should ensure that nothing else is broken. However, before releasing any product or module that is build upon the API, you should run a full test suite.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.