Vim: checking PHP code (and Python and...)

2013-02-03T00:32:00+01:00

Do you hate it as much as I do when you are writing some PHP (or Python or whatever) code in your favorite editor, hit 'save', reload the page in the browser in the hopes that you will see the new most awesome feature you ever wrote, but instead you are greeted by an unfriendly PARSE_ERROR_YOU_FORGOT_A_CLOSING_BRACKET_YOU_STUPID-error? Right, it feels like you just built a rocket, but upon launch you discover you didn't foresee a doorknob and can't get in anymore...

Luckily, if you are using Vim there is a nice plugin to quickly catch these errors (and more). The plugin I'm talking about is Syntastic. The plugin is built as a generic framework to run and process the result of a syntax checker. The syntax checkers themselves are specific for each language. Most of the syntax checkers start an external syntax checker or linter and return the output to Syntastic, telling it how to parse it.

By default Syntastic will automatically run the correct checker every time you save the file. When Syntastic finds some errors or warnings in your code, it can show signs on the offending lines and open a window at the bottom with an overview of the problems (depending on your Syntastic configuration). Using the window with the errors (a Vim location list) you can quickly jump to the lines with errors and warnings. In my configuration Syntastic will automatically open the location list whenever there is a problem and will also close the Location list once the problem is fixed.

Syntastic has support for over 50 languages, including PHP, Python, Ruby, CSS, Puppet, and so on. For a lot of languages, Syntastic comes with support for some alternative or supplementary syntax checkers. For PHP, Syntastic will first use the PHP built-in linter (`php -l`). If you also have PHP_CodeSniffer and/or PHP Mess Detector installed it will also run these tools on your file. For Python it depends on which tools you have installed. If you have only Python, Syntastic will use that and notify you of any syntax errors. Personally I like to use flake8 as it checks both your style against PEP8 rules and also checks your code with pyflakes.

One problem you can have with running extensive checks on your code is that you are overwhelmed by the number of errors and warnings. You have to tame the beast or you will drown in the errors and just ignore them. Luckily this is not verify difficult. When developing Drupal code the first step is to install the PHP_CodeSniffer ruleset for Drupal. This is part of the coder module. However, in my opinion this will still give you too many errors (seriously, is anyone still coding on a computer screen which only has 80 columns??). The easiest solution to this is to create your own ruleset. This is rather easy:

First install the Drupal ruleset at the correct location in PHP_CodeSniffer. On a *nix system this can be done by symlinking: sudo ln -s /path/to/coder/coder_sniffer/Drupal $(pear config-get php_dir)/PHP/CodeSniffer/Standards/Drupal
Create a new ruleset.xml and refer to the Drupal ruleset to import the entire ruleset.
In your own ruleset.xml you can exclude rules from the imported ruleset to disable them.

Have a look at my Drupal Ruleset for PHP_CodeSniffer at github for inspiration. For PHP Mess detector the system is pretty much the same. Here is my ruleset for PHP Mess Detector at github.

After you have created your personalized rulesets you have to configure Syntastic to use your own rulesets. This can be done by setting the g:syntastic_phpcs_conf and g:syntastic_phpmd_rules variables from your .vimrc file. You can see my Syntastic configuration in my vimrc at github.

UnitTesting PHP

2005-06-17T15:07:00+02:00

Once you've discovered the advantages of unittests you'll never want to write one single line of code without a test for it (well allmost ;)). You'll become "test-infected" :).

A few months ago, while doing a project in .NET, I discovered these advantages. Having unittests for your code helps you to refactor your code and add new/modified features to your application without having to fear that you'll break your code. Ofcourse you can still break your code, but if you have good unittests you'll immediately notice that you broke something and, depending on how good your tests are, you will also know where you broke something. When you have UnitTests you'll feel a lot safer when touching your code.

Today allmost every language has one or more unittesting frameworks. Most of them are based on JUnit, and are called xUnit frameworks. One example is NUnit, which is the JUnit port to .NET. Also PHP has it's unittesting frameworks, of which PHPUnit and SimpleTest are the best known.

SimpleTest is not just an xUnit framework. Apart from the classic TestCase and assert-methods it also offers support for Mock-objects and Stubs, webpage testing to load webpages and verify them, testing forms, authentication tests and a scriptable browser.

To illustrate it a bit, i'll give a, rather dumb, example. Suppose you create some Calculator class, which has a method 'multiplyByTwo($number)':

<?php
/**
 * a KISS calculator.
 */
class Calculator {
  /**
   * This method takes a number and multiplies it by 2.
   * @param int $number the number
   * @return int the multiplied number
   */
  function multiplyByTwo($number) {
    return $number * 2;
  }
}

Now you want to ensure that your multiplyByTwo-method works. Therefore you write a unittest:

<?php
class TestCalculator extends UnitTestCase {

   /**
    * The calculator under test.
    */
   var $_calculator;

   /**
    * This method is run before every test, and can be used to
   * prepare the environment.
   */
  function setup() {
    $this->_calculator = new Calculator();
  }

  /**
   * This method is run after every test and can be used to clean
   * the environment.
   */
  function teardown() {
    // nothing to tear down curretly. An example could be to
    // close a database connection
  }

  /**
   * Tests the multiplyByTwo method. (this is the actual test)
   */
  function testMultiplyByTwo() {
    $result = $this->_calculator->multiplyByTwo(5);
    $this->assertEqual(10, $result);
  }
}

Explanation: You see three methods in the testclass:

setUp(): This method is executed before every testmethod and can be used to prepare your environment. It is very likely that we will add more methods to our calculator which we will also have to test. Therefore we use the setUp()-method to create an instance of Calculator, so that this is automatically done for every test in the testclass.
tearDown(): is the same as setUp() but after the testmehod. This can be used to cleanup the environment.
testMultiplyByTwo(): This is the actual test. By convention it is named 'test' followed by a name which describes what the method tests.

What happens in testMultiplyByTwo is the following: First we invoke the multiplyByTwo method on the calculator instance, which was automatically created by the setUp()-method, and store the result in $result. Because we give 5 as the method's parameter we know the result should be 10, if the method works as expected. This expectation is tested with the assertEqual method, which takes an expected value (10) and the actual result ($result). As an optional parameter it takes a string in which you can explain your expectation, it will be printed when the test fails and can help you determine what went wrong. The assertEqual method then verifies if both values are equal. If so the test passes, if not your test failes and you know you have a bug in your code! ofcourse there are a lot more assert-methods, like assertNotNull, assertTrue, assertIsA and so on.

To run your test you can use the following code:

<?php
$test = &new TestCalculator();
$test->run(new HtmlReporter());

If your code works (which is very likely in this example :) ), you'll get a nice green bar, telling you how many tests succeeded. However as soon as one or more tests fail you get an ugly red bar screaming for you attention and telling you how many, and more important, which, tests failed. You can try this by changing the '2' inside multiplyByTwo in 3 and enjoy the red bar.

I hope this example has illustrated that you can sleep on both ears if you have enough tests to cover all your code and you keep the bar green :)

teranex weblog - PHP

Vim: checking PHP code (and Python and...)

UnitTesting PHP