The SitePoint PHP blog has a tutorial posted talking about the automated testing of Drupal 8 modules, the components of the popular PHP-based content management system. In it author Daniel Sipos shows how to create a few tests for some functionality created in previous articles.

In this article we are going to look at automated testing in Drupal 8. More specifically, we are going to write a few integration tests for some of the business logic we wrote in the previous Sitepoint articles on Drupal 8 module development. [...] But before doing that, we will talk a bit about what kinds of tests we can write in Drupal 8 and how they actually work.

He makes use of the SimpleTest unit testing tool for PHP (versus something like PHPUnit) as it has become a standard for Drupal's own testing. He talks briefly about what SimpleTest is, how it integrates with Drupal and what kinds of tests already exist. He then gets into testing his own functionality - checking route information, that the page exists, the contents of the resulting page and the addition of a custom block plugin. He shows how to create these simple tests, extending the WebTestBase class, and checking each item on the list. He also includes an example of the resulting output of the successful testing, including time to execute and the detailed results of each test.

On DZone.com today there's a new post written up by Mike Bernat about making web test cases for CakePHP applications with SimpleTest.

Most of the applications I work on have very straight-forward components and not a lot of complex functions/methods. I would only be testing whether or not they worked at all, rather than if they worked in a wide-array of situations. [...] For example, unit-testing a simple news list and detail page is probably overkill. Sure, you can test your classes by simple instantiating them but that only goes so far. My new method involves using SimpleTest's Scriptable Browser to actually crawl webpages and ensure that the proper data is being displayed.

He includes a few snippets of code to show how to implement SimpleTest's web test functionality - one that just checks a HTTP response values, another that checks for text on the page, one testing for a login on an admin page and a test for add/edit pages to ensure valid loading based on URLs/links.

Warren Tang has put together this new post to his blog showing how you can use the SimpleTest extension for Eclipse to execute your tests without leaving the IDE.

He breaks it down into a few simple steps (some including screeshots):

• Download the plugin
• Install and configure
• Create a basic test with an assertion
• Run the test via "Run As > SimpleTest"

He also includes the option for running the test as a web page, but that requires a little bit more code. There's also a quick look at how to run a suite of tests from the IDE (as well as in the browser). for more about using SimpleTest, head over to the project's site.

On PHPBuilder.com today there's a new tutorial showing you how to write and run unit tests with SimpleTest to test the interface of your site (forms), not just the backend code.

In addition to offer a complete suite of unit testing capabilities, SimpleTest is bundled with an internal Web browser which you can use to automate the navigation of your Web site and perform tests such as completing and submitting Web forms much in the same way a typical user would. In this tutorial, I'll show you how to use SimpleTest to automate these otherwise tedious tasks.

He starts with the basics of installing the tool and and running the sample test to ensure things are set up correctly. They include tests that show how to check for a successful form submission by checking things like response code and contents of the text on the result page.

On NETTUTS.com today there's a new tutorial to help you get started with effective test-driven development in your PHP applications with SimpleTest.

Testing your code is annoying, but the impact of not doing so can be orders of magnitude more annoying! In this article, we’ll use test-driven development to write and test our code more effectively.

They start with the basics - what test-driven development is, why it's a good idea and how the whole process works to improve your code. They opt for a bit simpler route for their testing tool and chose SimpleTest. They show you how to set it up and where to start. In order for TDD to work, you really have to plan out your application so you know what you're testing. They give you an example of a simple script and how to start from failing tests to a working app.

Josh Butts pointed out a new tool for those creating unit tests (either in PHPUnit, SimpleTest or any other PHP unit testing framework) that work with databases that replaces fixtures - Phactory.

Phactory is an alternative to using database fixtures in your PHP unit tests. Instead of maintaining a separate XML file of data, you define a blueprint for each table and then create as many different objects as you need in your PHP code. By using a database factory instead of fixtures, your unit tests will be more clear and easier to write. You’ll also be able to change the objects you create programmatically instead of being stuck with the same old fixtures.

The tool gives you a light-weight ORM to use in your tests and, once you define a PDO connection, lets you interact with the objects just like they were normal tables. An example is included on the main page of the site and the code for the project can be found on github.

On the TigerFish Interactive blog today there's a new post for Drupal-ers out there about using the SimpleTest plugin for Drupal 6 to run automated tests against Ajax callbacks.

In Drupal 6's excellent SimpleTest module, a method called drupalPost() allows you to simulate a button press on a form by taking the form's data and using HTTP POST to submit it. But what if you want to POST data to an AJAX callback URL? By default, SimpleTest checks which submit button you have pressed, but of course, when POSTing using AJAX, you probably won't have pressed a button!

After doing some searching on a problem he had - submitting a form without the actual form on a page - he decided the best solution was to create a base class that inherits from DrupalWebTestCase. This base class allowed him to make a POST request (via curl) to the page and simulate a form request. The code for the method is included.

According to this new post from Mark Story (and this article on The Bakery) the CakePHP project has moved away from simpletest as their testing tool of choice and has picked up PHPUnit.

In the recent bakery article concerning the ongoing development of CakePHP 2.0. The already underway migration from SimpleTest to PHPUnit was introduced. I wanted to go into some of the reasons and motivations for that decision as well as explain some of the long term benefits.

He lists some of their thoughts behind making the move including the fact that SimpleTest isn't E_STRICT compliant and that the integration of PHPUnit into some of the popular continuous integration and deployment tools makes it an obvious front-runner. Of course, there'll be a bit of pain as the transition is made, but the new tool will give much more insight into the CakePHP codebase. Most of the tests will translate relatively easily, though.

Noting the lack of a good, independent library for creating Mock Objects for unit testing PHP scripts, Padraic Brady (with assistance from Travis Swicegood) has come up with a standalone Mock Object and Stub framework - Mockery.

It's not tailored specifically to any one testing framework, rather it's an entirely separate framework with a discrete API. The idea is that you can use this framework within PHPUnit, or SimpleTest, or anything else really, without being forced to rely on the built-in support (if any) that test framework provides. Mockery was designed specifically to implement a form of Domain Specific Language (DSL). It makes extensive use of a fluent interface mixed with methods to approximate plain English.

He includes an overview of what Mock Objects and Stubs are and how to set them up with the Mockery tool. He finishes things off with a look at the Mockery and Mock Object Expectation APIs. You can grab this first release either as a PEAR package or from its github page.

On the Developer Tutorials blog, there's a recent example of how to validate a common task of many signup forms - if the email sent is actually received.

For any web developer that's ever had to build a signup routine, email is the necessary evil that takes pride of place among hated activities. Sure, a simple call to the language's mail library will send a message through, but the moment the boss wants a HTML email, or users need attachments, everything starts to get tricky.

They try to solve the mail return issue (it tells if the message has gone to the queue, not been delivered) with a little testing and Fakemail. The software looks for emails based on the configuration given and pulls them out to a local directory. Your script can then look here and check the validity of the message before its sent.

This even allows for integration with things like Phing, SimpleTest and Selenium.