DZone
Web Dev Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Web Dev Zone > Practical PHP Testing Patterns: Automated Teardown

Practical PHP Testing Patterns: Automated Teardown

Giorgio Sironi user avatar by
Giorgio Sironi
·
Feb. 20, 11 · Web Dev Zone · Interview
Like (0)
Save
Tweet
692 Views

Join the DZone community and get the full member experience.

Join For Free

The idea behind the Automated Teardown pattern is to keep track of all resources of a certain kind (like sockets, or database connections, or opened files), in order to perform an automatic release after the tests have terminated.

Remember that teardown is usually not needed in unit tests and in any tests that primarily works on in-memory objects; however, functional and above all integration tests often needs to access external resources, which PHP by itself doesn't know how to shutdown.

To ensure test isolation, at the end of a test we may destroy everything that has been used. Whether or not putting the hook for this logic in teardown() is a orthogonal to the use of this pattern. The important thing here is to have a cleanUpEverything() method that you can call without worries, because it will be able to find each resource to clean up.

Why a tear down?

Connections, sockets, files, and even objects may result in performance degradations if we do not destroy them after tests. Imagine running a long test suite and filling up some gigabytes of memory because tests do not clean the dishes.

Teardown is also related to global state we can't avoid, like an interaction with the filesystem, or frameworks configurations in static fields and singletons. It's important to restore the state that was in place before the tests, to avoid producing some ripple effects from a test to another.

Why automatically?

A complex teardown results in obscure tests, and also in introduction of bugs.

If you have an Automated Teardown, you cannot forget to close that connection or to delete that temporary file: a good automated mechanism, once it works, has not to be configured further.

Implementation

There are several simple steps for implementing Automated Teardown:

  • wrap creation into a mechanism that keep references to all the created items. You can search for unauthorized creations in the test suite by grepping 'new MyClass' or 'fopen(', or something similar.
  • call the wrapper when you need resources and let your tests perform their act and assert phases.
  • at the end of the test, you can tell the registry to clean up.

As a side note, this mechanism is similar to how garbage collection is implemented manually in languages where it is not supported (reference counts, and so on).

Gargabe collection works well for objects, but not all the resources are objects (especially in PHP) nor they can be always torn down by simply deleting the object (closing a connection doesn't mean the database will be deleted). An external connection may need explicit closing; a file on the filesystem may need to be rewritten in its original version.

However, beware of relying on teardown instead of setup to get to a known state: a failing test would leave you in a terrible situation. It's ok to delete files created by tests in teardown; it's not ok to setup the file that every test expects. If a test expects a file, it's his responsibility to put it there, not of the test before (Shared Fixture does this, and in fact it is more fragile than the other patterns).

We'll see more on this in the next articles on teardown, but a common failure mode for the latter choice will be a Fatal Error: when the suite abrubtly stops due to a method called on null, you won't be able to restart it because the state is corrupt (the reason being that the teardown was not executed since PHP immediately exited). Setup phases instead are always executed.

Examples

This sample Testcase class shows you how to implement a register for temporary files, so that you can test classes that interact with the filesystem (hopefully only in integration tests) and not worrying about deleting all that temporary files. It's also downloadable from Github.

<?php
class AutomatedTeardownTest extends PHPUnit_Framework_TestCase
{
/**
* @var array Paths to all files created in the tests.
*/
private $files;

public function testTheSutSumsANumberToTheNumbersInTheFile()
{
$file = $this->createTextFile("1\n2\n3\n");
$sut = new Raiser(10);
$sut->raise($file);

// make your assertions...
}

/**
* Wrapped creation of resources, in this case files
*/
private function createTextFile($content)
{
$file = uniqid('temp') . '.txt';
file_put_contents($file, $content);
$this->files[] = $file;
return $file;
}

/**
* Hook for executing the teardown at the end of each test.
* You can also execute it manually: the automation resides in not having
* to specify where are the resources to clean up.
*/
public function teardown()
{
$this->cleanUpAllFiles();
}

/**
* Automated Teardown implementation
*/
private function cleanUpAllFiles()
{
foreach ($this->files as $filePath) {
unlink($filePath);
}
}
}

class Raiser
{
private $delta;

public function __construct($delta)
{
$this->delta = $delta;
}

public function raise($file)
{
$content = file_get_contents($file);
$lines = explode("\n", $content);
foreach ($lines as $line) {
if (is_numeric($line)) {
$line += $this->delta;
}
}
$content = implode("\n", $lines);
file_put_contents($file, $content);
}
}
PHP unit test

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Version Number Anti-Patterns
  • Artificial Intelligence (AI) And Its Assistance in Medical Diagnosis
  • Applying Domain-Driven Design Principles to Microservice Architectures
  • How to Classify NSFW (Not Safe for Work) Imagery with AI Content Moderation using Java

Comments

Web Dev Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo