Archive for November 2009
Command-line memcached stat reporter
Nicholas Tang wrote a nice little perl script that shows a basic memcached top display for a list of servers. You can specify thresholds, for instance, and it’ll change color to red if you exceed the thresholds. You can also choose the refresh/sleep time, and whether to show immediate (per second) stats, or lifetime stats.
To install it you only need to download the script and make it executable:
$ curl http://memcache-top.googlecode.com/files/memcache-top-v0.6 > ~/bin/memcache-top $ chmod +x ~/bin/memcache-top $ memcache-top --sleep 3 --instances 10.50.11.3,10.50.11.4,10.50.11.5
Here’s some sample output:
memcache-top v0.6 (default port: 11211, color: on, refresh: 3 seconds) INSTANCE USAGE HIT % CONN TIME EVICT/s GETS/s READ/s WRITE/s 10.50.11.3:11211 88.9% 69.7% 1661 0.9ms 0.3 47 13.9K 9.8K 10.50.11.4:11211 88.8% 69.9% 2121 0.7ms 1.3 168 17.6K 68.9K 10.50.11.5:11211 88.9% 69.4% 1527 0.7ms 1.7 48 14.4K 13.6K AVERAGE: 84.7% 72.9% 1704 1.0ms 1.3 69 13.5K 30.3K TOTAL: 19.9GB/ 23.4GB 20.0K 11.7ms 15.3 826 162.6K 363.6K (ctrl-c to quit.)
Project Home
http://code.google.com/p/memcache-top/
Managing Multiple Build Environments
Last updated: 3 March, 2010
One of the challenges of Web development is managing multiple build environments. Most applications pass through several environments before they are released. These environments include: A local development environment, a shared development environment, a system integration environment, a user acceptance environment and a production environment.
Automated Builds
Automated builds provide a consistent method for building applications and are used to give other developers feedback about whether the code was successfully integrated or not. There are different types of builds: Continuous builds, Integration builds, Release builds and Patch builds.
A source control system is the main point of integration for source code. When your team works on separate parts of the code base, you have to ensure that your checked in code doesn’t break the Integration build. That’s why it is important that you run your unit tests locally before checking in code.
Here is a recommended process for checking code into source control:
- Get the latest code from source control before running your tests
- Verify that your local build is building and passing all the unit tests before checking in code
- Use hooks to run a build after a transaction has been committed
- If the Integration build fails, fix the issue because you are now blocking other developers from integrating their code
Hudson can help you automate these tasks. It’s extremely easy to install and can be configured entirely from a Web UI. Also, it can be extended via plug-ins and can execute Phing, Ant, Gant, NAnt and Maven build scripts.
Build File
We need to create a master build file that contains the actions we want to perform. This script should make it possible to build the entire project with a single command line.
First we need to separate the source from the generated files, so our source files will be in the “src” directory and all the generated files in the “build” directory. By default Ant uses build.xml as the name for a build file, this file is usually located in the project root directory.
Then, you have to define whatever environments you want:
project/
build/
files/
local/
development/
integration/
production/
packages/
development/
project-development-0.1-RC.noarch.rpm
integration/
production/
default.properties
local.properties
development.properties
production.properties
src/
application/
config/
controllers/
domain/
services/
views/
library/
public/
tests/
build.xml
Build files tend to contain the same actions:
- Delete the previous build directory
- Copy files
- Manage dependencies
- Run unit tests
- Generate HTML and XML reports
- Package files
The target element is used as a wrapper for a sequences of actions. A target has a name, so that it can be referenced from elsewhere, either externally from the command line or internally via the “depends” or “antcall” keyword. Here’s a basic build.xml example:
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="project" basedir="." default="main">
<target name="init"></target>
<target name="test"></target>
<target name="test-selenium"></target>
<target name="profile"></target>
<target name="clean"></target>
<target name="build" depends="init, test, profile, clean"></target>
<target name="package"></target>
</project>
The property element allows the declaration of properties which are like user-definable variables available for use within an Ant build file. Properties can be defined either inside the buildfile or in a standalone properties file. For example:
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="project" basedir="." default="main">
<property file="${basedir}/build/default.properties" />
<property file="${basedir}/build/${build.env}.properties" />
...
</project>
The core idea is using property files which name accords to the environment name. Then simply use the custom build-in property build.env. For better use you should also provide a file with default values. The following example intends to describe a typical Ant build file, of course, it can be easily modified to suit your personal needs.
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="project" basedir="." default="main">
<property file="${basedir}/build/default.properties" />
<condition property="build.env" value="${build.env}" else="local">
<isset property="build.env" />
</condition>
<property file="${basedir}/build/${build.env}.properties" />
<property environment="env" />
<condition property="env.BUILD_ID" value="${env.BUILD_ID}" else="">
<isset property="env.BUILD_ID" />
</condition>
<target name="init">
<echo message="Environment: ${build.env}"/>
<echo message="Hudson build ID: ${env.BUILD_ID}"/>
<echo message="Hudson build number: ${env.BUILD_NUMBER}"/>
<echo message="SVN revision: ${env.SVN_REVISION}"/>
<tstamp>
<format property="build.datetime" pattern="dd-MMM-yy HH:mm:ss"/>
</tstamp>
<echo message="Build started at ${build.datetime}"/>
</target>
<target name="test">
...
</target>
<target name="clean">
<delete dir="${build.dir}/files/${build.env}"/>
<delete dir="${build.dir}/packages/${build.env}"/>
<mkdir dir="${build.dir}/files/${build.env}"/>
<mkdir dir="${build.dir}/packages/${build.env}"/>
</target>
<target name="build" depends="init, test, profile, clean">
...
</target>
...
</project>
Using ant -Dname=value lets you define values for properties on the Ant command line. These properties can then be used within your build file as any normal property: ${name} will put in value.
$ ant build -Dbuild.env=development
There are different ways to target multiple environments. I hope I have covered enough of the basic functionality to get you started.
Testing Zend Framework Action Controllers With Mocks
In this post I’ll demonstrate a unit test technique for testing Zend Framework Action Controllers using Mock Objects. Unit testing controllers independently has a number of advantages:
- You can develop controllers test-first (TDD).
- It allows you to develop and test all of your controller code before developing any of the view scripts.
- It helps you quickly identify problems in the controller, rather than problems in one of the combination of Model, View and Controller.
The Action Controller I’m going to test has only one method, profileAction():
tests/application/controllers/UserController.php
class UserController extends Zend_Controller_Action
{
public function profileAction()
{
$this->view->userId = $this->_getParam('user_id');
return $this->render();
}
}
tests/application/ControllerTestCase.php
class ControllerTestCase extends Zend_Test_PHPUnit_ControllerTestCase
{
public $application;
public function setUp()
{
$this->application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/config/application.ini'
);
$this->bootstrap = array($this, 'bootstrap');
parent::setUp();
}
public function tearDown()
{
Zend_Controller_Front::getInstance()->resetInstance();
$this->resetRequest();
$this->resetResponse();
$this->request->setPost(array());
$this->request->setQuery(array());
}
public function bootstrap()
{
$this->application->bootstrap();
}
}
tests/application/controllers/UserControllerTest.php
require_once TESTS_PATH . '/application/ControllerTestCase.php';
require_once APPLICATION_PATH . '/controllers/UserController.php';
class UserControllerTest extends ControllerTestCase
{
public function testStubRenderMethodCall()
{
$request = $this->getRequest()
->setRequestUri('/user/profile/1')
->setParams(array('user_id'=>1))
->setPathInfo(null);
$response = $this->getResponse();
$this->getFrontController()
->setRequest($request)
->setResponse($response)
->throwExceptions(true)
->returnResponse(false);
$controller = $this->getMock(
'UserController',
array('render'),
array($request, $response, $request->getParams())
);
$controller->expects($this->once())
->method('render')
->will($this->returnValue(true));
$this->assertTrue($controller->profileAction());
$this->assertTrue($controller->view->user_id == 1);
}
}
You can go further making both the tests and the implementation more sophisticated. The main point is that you can build and test a controller in a way that doesn’t require a view script to be written to do so.
Zend Framework Known Issues
By default Zend_Test_PHPUnit_ControllerTestCase sets the redirector exit value to false, leading to unexpected behavior when unit testing your code. For that reason, make sure you always add a return statement after calling a utility method:
class UserController extends Zend_Controller_Action
{
public function profileAction()
{
if (null == $this->_getParam('user_id', null) {
return $this->_redirect('/');
}
return $this->render();
}
}
If you want the Front Controller to throw exceptions, you have no other choice than to overwrite the dispatch method and pass a boolean TRUE to the throwExceptions() method:
class ControllerTestCase extends Zend_Test_PHPUnit_ControllerTestCase
{
...
public function dispatch($url = null)
{
// redirector should not exit
$redirector = Zend_Controller_Action_HelperBroker::getStaticHelper('redirector');
$redirector->setExit(false);
// json helper should not exit
$json = Zend_Controller_Action_HelperBroker::getStaticHelper('json');
$json->suppressExit = true;
$request = $this->getRequest();
if (null !== $url) {
$request->setRequestUri($url);
}
$request->setPathInfo(null);
$this->getFrontController()
->setRequest($request)
->setResponse($this->getResponse())
->throwExceptions(true)
->returnResponse(false);
$this->getFrontController()->dispatch();
}
...
}
The Dispatcher not only violates the DRY principle but also suffers from amnesia. The problem is that it doesn’t store the instance of the Action Controller, instead, it destroys it (Zend_Controller_Dispatcher_Standard Line 305). You can easily get around this issue by extending the standard dispatcher and overwriting the dispatch() method:
class Zf_Controller_Dispatcher_Standard extends Zend_Controller_Dispatcher_Standard
{
...
public function dispatch($url = null)
{
...
Zend_Registry::set('Zend_Controller_Action', $controller);
// Destroy the page controller instance and reflection objects
$controller = null;
}
This will allow you to access the view object after dispatching the request:
class ExampleControllerTest extends ControllerTestCase
{
public function testDefaultActionRendersViewObject()
{
$this->dispatch('/');
$controller = Zend_Registry::get('Zend_Controller_Action');
$this->assertEquals('ExampleController', get_class($controller));
$this->assertTrue(isset($controller->view));
}
Links
PHPUnit: Testing Zend Framework Controllers
PHPUnit: Mock Objects
