Developers write tests for a variety of different reasons and understanding why, and how, writing tests can improve the quality of our code and our sanity helps motivate ourselves to write tests. The tests we write usually take one of two forms. Functional tests are used to test an applications behavior. When I click this link does it take me to the about page? Unit tests are used to verify the logic within a small segment, or unit, of code. When I call this function that is supposed to return a link with these specific parameters does it return the correct data? There are a ton of reasons that investing time and resources into writing automated tests is a big win in the long run and in this lesson we'll cover a bunch of them, including:

• Eliminate repetitive tasks.
• Improve overall stability of an application.
• Ensure critical paths & edge cases function.
• Reduce (not eliminate) the number of tests that need to be performed manually.

Types of Tests

There are are two main types of tests and we're going to be writing. Functional tests, and Unit tests.

Functional tests, also known as integration tests, test the functionality of a particular aspect of an application by simulating normal interaction with that system. In the case of web software this usually refers to simulating a user navigating and interacting with the website as if they where using their browser, keyboard, and mouse.

Unit testing is the art and practice of taking a small portion of code, a unit, and subjecting it to programmatic tests to prove its correctness. For example, testing a function that performs unit conversion by comparing a known input with an anticipated result.

UPDATE: This video references qa.drupal.org which is no longer in use. On Friday, October 23rd 2015 - qa.drupal.org received and processed it's last
test. The qa.drupal.org testbots have now been superseded by DrupalCI - and test results are now displayed directly on Drupal.org. While the mechanics are different now, the end result is still all patches to Drupal core are automatically tested.

Before we get into writing our own tests we need to enable the SimpleTest module, and while we're at it we may as well talk about the various configuration options it has. And then why not run a few of the tests that come with Drupal core as a way to learn how to discover and run all the tests, a group of tests, or even an individual test case.

The SimpleTest module comes with Drupal 7 core, but is not enabled by default. So we can start by enabling the module. On the administration page for enabling modules the module is listed as "Testing" instead of SimpleTest which can be a bit confusing. The the UI you'll almost always see the name "Testing", but in the code, documentation, and at the command line it's generally referred to as SimpleTest.

Once the module is enabled there are just a few new permissions and configuration options to cover. The new 'run tests' permission, and a couple of settings related to enabling verbose output for debugging of tests. Make sure you check them all out.

Tests can be run in a variety of different ways, either from your browser using the Testing module's UI, or at the command line with drush. We'll cover both of them in this lesson. And in doing so we'll look at how to run a group of tests, or an individual test case, and the output that's generated by running tests.

I've also got a module (which you can download from this page) that contains a couple of failing tests. This way we can run a test case that fails, and see what the output looks like from a failure. SimpleTest outputs some helpful debugging information, and with the verbose option enabled will even save the generated HTML of each page the SimpleTest browser saw so that we can review it after the test run is complete.

If you're not familiar with drush checkout our series on using drush.

By the end of this lesson you should be able to enable and configure the simple test module and run some tests.

Example drush commands

Run all tests in the "Block" group:

drush -l http://localhost/demos/simpletest-7x/docroot test-run Block

Run just the "BlockHashTestCase" test case:

drush -l http://localhost/demos/simpletest-7x/docroot test-run BlockHashTestCase

Note: as of Drush 7 the drush test-run command is no longer part available. See https://github.com/drush-ops/drush/issues/599.

You can either, use Drush 6, or use the scripts/run-tests.sh scrip that comes with Drupal core. See the documentation for the run-tests.sh script for more information.

SimpleTest is the tool that Drupal 7 core uses for discovering, and running all of it's tests. SimpleTest is also the name of the system that is used to write tests that can be run by the SimpleTest module. Understanding how SimpleTest locates the code that makes up our tests, and then executes that code, is an important part of understanding how to write tests. In this lesson we'll be discussing the pieces that make up the SimpleTest toolkit, some related terminology, and some best practices for dealing with SimpleTests in Drupal.

Methodology

Some best practices to keep in mind when working with SimpleTest and writing tests.

• Tests should always be run in a separate environment from your production site.
• Each test case sets up a completely new Drupal env, as such your test case needs to prepare the new environment as appropriate for your tests. Things like enabling any necessary modules, creating dummy content, and users etc. For this reason, it's best to have tests that require a similar setup be part of the same test case for better performance.
• After a test case is run the environment is torn down and started fresh for the next test case. This ensures there is no contamination between test cases and that each test can count on knowing exactly what to expect from the environment it's running in.
• SimpleTest is not always ideal for doing functional testing of your existing site. Drupalize.Me for example, we want to test that our About page is visible. But that's content, and doesn't live in code anywhere so creating it at install time can be tricky: We'll cover this scenario in more depth later.
• Always test both sides of the problem. If your site only allows authenticated users to make comments, and you write a test to make sure authenticated users can comment you'll also want to make sure you write a test that verifies that anon. users can not comment. If you're checking that a value exists under specific conditions, also verify that it doesn't exist when those conditions are not met

Terminology

SimpleTest: The original name of the module used for testing in Drupal. Though it's now called just "Testing", the terms are used interchangeably. Based on the PHP SimpleTest library.

Test Case: A set of conditions under which the tester will determine whether the system being tested satisfies requirements and works correctly. A Test case defines the environment in which a test or set of tests will run. Including preconditions such as what modules are enabled, what content exists, etc. It is assumed that these same preconditions are true for all individual tests within a test case.

In Drupal, all test cases are classes that extend the DrupalWebTestCase, or the DrupalUnitTestCase class.

Test (Test method): Each individual test checks the functionality of one discreet thing. Example, if our test case is "User cancellation" there are many variations of cancellation that we need to test. Cancel the account and keep their content, cancel the account and delete their content, don't allow cancellation of the account with UID 1, etc. Each of these individual tests is checking one piece of functionality with the test case.

Assertion: The smallest unit of a test. An assertion is used to check wether or not a given condition is true in the current context.

Additional resources

Testing, and quality assurance, are an important part of maintaining high-quality software. Together they ensure that the code we write functions as it is intended to, and that changes made later on do not introduce any regressions into our application. Its tedious work and generally involves coming up with a list of tasks that prove a specific feature is working, and then repeating the list of tasks every time a change is made.

Automated testing is the process of writing code to reduce the number of things we need to do manually when testing our software. That list you created to ensure your software is working correctly is likely something that can be easily automated with a testing framework like SimpleTest. Doing so can dramatically reduce the amount of time it takes to perform QA, and improve the overall stability of our applications.

The SimpleTest testing framework was introduced into Drupal core early on in the Drupal 7 development cycle. Since then it has had a profound impact on the way our community develops Drupal. Core now contains a whole suite of tests that cover somewhere in the neighborhood of 75% of the softwares functionality. Every time a new features is introduced, or a bug is fixed, this battery of tests confirms that the fix to the date formatting function didn't inadvertently break something else.

In this series we'll learn to write our own automated tests for Drupal 7 using SimpleTests. We'll walk through enabling SimpleTest, and running one or more test cases with both the SimpleTest UI, and with drush. Then we'll cover some of the related terminology like the difference between functional tests and unit tests. As well as discuss why testing is an important part of development and worth the investment.

Then we'll walk through writing a test case and a set of assertions in orders to verify that various features of our site are working. We'll use functional tests based on the DrupalWebTestCase class, which simulates a browser navigating our site and clicking on links, and filling out forms. And the DrupalUnitTestCase class, which allows us to write super fast unit tests for the business logic contained within our code.

After watching this series you should be able to:

• Install the SimpleTest module and run the tests included with core.
• Define and know the difference between functional tests, unit tests, test cases, and assertions.
• Create a new test case so that SimpleTest can discover and run your tests.
• Write assertions that test the validity of your application in a given state.
• Use the test browser to click on links and navigate to pages on a site.
• Fill out and submit forms and AJAX form elements using the test case browser.
• Handle file and image uploads in test cases.
• Write unit tests, and understand how the workflow for running unit tests differs from that of functional tests.
• Use the SimpleTest 7.x-2.x module from contrib to test existing websites.

This series assumes that you have basic understanding of Object Oriented PHP, and are familiar with Drupal module development. If you need to brush up on your module development watch our series on Drupal 7 Module Development. And, while not required to run tests, we do make use of drush in this series so knowing how to run drush commands is helpful.

Writing tests can be a challenging. But it doesn't have to be. And the benefits of doing so are huge. Especially as our web applications become more complex, as our teams grow, and as the multitude of ways in which people interact with our web applications changes constantly. Spending some time learning how to write tests will not only make your applications more reliable, it'll also make you a better developer.

Additional resources

• Drupal 7 Module Development series
• Introduction to Drush

YAML, which stands for YAML Ain't Markup Language, is a human-readable data serialization format that's been widely adopted in a variety of use cases in Drupal. Anyone wanting to write modules, or themes, for Drupal will need to understand YAML syntax. Even site builders are likely to encounter YAML at least in passing as YAML is the data-serialization format of choice for Drupal's configuration management system. Good thing it's pretty easy to learn even with the most basic of programming backgrounds.

This tutorial will look at the YAML data format and provide examples of how to write and read YAML. Starting with an introduction to the language's syntax and some of the strengths of YAML. Then looking at the difference between scalar data types like strings and integers, and collection data types like lists and associative arrays.

Since YAML in the Drupal world is read into PHP and ultimately becomes a PHP data structure that we can use in our own code we'll also look at how the YAML we write in a .yml file is represented in PHP data types. To do this we'll use the YAML Sandbox module that provides a handy textarea into which we can type YAML and have it parsed into PHP data structures.

Learning objectives

• Explain what YAML is and its strengths as a data serialization format
• Create scalar key/value pairs in YAML
• Create lists, and associative arrays using YAML collections
• Understand how the YAML you write is represented in PHP

Tips

• In Drupal, use the .yml extension and not .yaml
• Ensure your code editing application is configured to use spaces (preferably 2 spaces, as per Drupal coding standards), not the tab character when the TAB key is pressed. If you have tab characters in a YAML file within a Drupal environment, a fatal PHP error will be thrown and you'll see a White Screen of Death (WSOD).
• Copy and paste from an existing YAML file to ensure the formatting is correct, and edit from there.

Additional resources

• http://www.yaml.org
• YAML Sandbox module
• Find other tutorials and external resources related to YAML on our YAML topic page (Drupalize.Me)

Some of the content that's been added to our case study site isn't responding ideally as the viewport size increases and decreases. We have an HTML table that is a bit too flexible, making the columns too narrow for the text inside them to be very readable. The images in our slideshow are presenting us with a problem when the screen size gets too big: the images are scaling up and losing their quality in the process. To address these miscellaneous problems, we'll change how our content is placed, find some new breakpoints, and add new media queries for our grid_6 regions. We'll also learn some CSS tricks that will transform our table data into lists, making it more legible and sensibly presented on smaller screens.

Additional resources

https://github.com/DrupalizeMe/demo-rwd-7x (checkout branch 14-cleaning-up)

As we design for mobile, we want to look critically at each component and what it's communicating or how it's adding value. Now that we've refactored our theme to be more mobile-friendly, some elements in our header appear redundant when viewed in a narrow, stacked content column. This is causing our header elements to fill up that important initial screen on mobile. We want to ensure that our valued mobile users get more content and fewer redundant header elements when the page first loads.

In this lesson, we'll identify a breakpoint where the header gets too cluttered with elements essentially communicating the same thing. Then we'll add a new set of media queries, creating styles that will present a more mobile-friendly first impression of our site.

Additional resources

https://github.com/DrupalizeMe/demo-rwd-7x (checkout branch 13-mobile-friendly-header)