Unit Tests

Unit tests are low level tests that measure the input and output of a single function or  class. Tests are written in a completely isolated environment where all the input values are specified and the class being tested does not communicate with other parts of the system. Each unit test has its output values compared against the expected results. Tests are written from a developers perspective who knows the details of the system.

Unit tests don’t tell you if your application is stable, but it can tell you if the unit tested classes or functions perform exactly as intended.

Examples are JUnit, PhpUnit and Lime (which we use).

Functional Tests

In some ways, functional tests are the opposite of unit tests because they are high level tests for actions users can perform on the system. They could be adding an item to a shopping cart or editing your profile. Functional tests are written from a users perspective to complete a task.

These tests confirm the system can successfully complete that task; this could be the store item appearing in your cart, or changes to profile actually being saved.

Example are Selenium, Silk or TestComplete.

Jakob Nielsen recommends using mega drop-down navigation menus over regular link-only drop down menus because of better usability.

His reasons are:

• Easier to present all the links without scrolling, instead of hiding them
• Can easy group related items together
• Illustrations can help explain links

Mega drop down menus may be the appropriate solution to use on a clients website if they have more than a few navigation links.

What do you think?

PHP 5.3.0 was release one month ago on June 30th with a couple of interesting new language features; some will make your life a bit easier, and some you will need to be aware of.

A brief summary of added features:

Namespace support, late static bindings, jump label (limited goto), native closures, native PHP archives (phar), garbage collection for circular references, vastly improved Windows support, persistent connections with mysqli, sqlite3, fileinfo as a replacement for mime_magic for better MIME support, ternary shortcut and the internationalization extension. Of these I believe the most interesting features are native closures, the ternary shortcut, and namespace support.

Closures, also called anonymous functions, allow you to create a function without a name. If you have ever programmed in JavaScript, you would have noticed they used often as callback functions. In PHP they are useful for the same thing. For example, the usort PHP function takes a callback function as an argument and would therefore be a good candidate for a one time custom sorting function:

usort($arr, function($a, $b) { return $a < $b ? 1 : -1; });

The new ternary shortcut is a very welcome syntax addition. The ternary shortcut allows a command to take the result of a variable if its set, or if its not defined or empty, fall back to a default value.

Before PHP 5.3, the syntax for getting the value would be:

$action = empty($_GET['action']) ? $_GET['action'] : 'home';

The ternary shortcut allows you to simplify this to:

$action = $_GET['action'] ?: 'home';

Namespace support is important because PHP libraries can now use regular class names without requiring prefixes. The symfony framework prefixes every single class with the ’sf’  token so it doesn’t clash with other PHP libraries that may want to have common class names like ‘WebController’. Collisions can be handled much easier now; if two packages are using the same class names and you want to use them in the same project, just put one of them in a namespace and continue coding, problem solved.

Unfortunately, the syntax is a bit expected:

namespace my\name;
$c = new \my\name\MyClass;

PHP 5.3 is a pretty decent update with many new feature that are critical for PHP to remain a competitive programming language. I encourage you to start thinking about how you can use these feature and even download the latest version and try them out.

Software Design Patterns are solutions to common problems that can be applied when developing software. They are well known and understood solutions to regular programming problems.

The factory method pattern is a design pattern for creating objects. The factory is responsible for creating objects, that is, using the new keyword. Every time you create objects of a certain type you delegate the task to the factory.

Lets say we have a system that can invite contacts from different email providers. The factory code would look like something like this in PHP:

class InviterFactory
{
  public static function getInviter($type)
  {
    switch ($type)
    {
    case 'gmail':
      $inviter = new GmailInviter();
      break;
    case 'hotmail':
      $inviter = new HotmailInviter();
      break;
    case 'yahoo':
      $inviter = new YahooInviter();
      break;
    default:
      $inviter = null;
    }

    return $inviter;
  }
}

In the future, if we ever add another email provider, say, canada.com, we would only have to add the CanadaInviter to the factory class, and our whole project is now ready to use this type of inviter.

The factory pattern is also good for unit testing. In unit testing we want to completely be able to control a small section of the program to test all possible inputs and outputs. When testing a section of code that uses the factory to create objects, we can replace the standard factory with a unit-test factory, that returns dummy objects with only enough functionality required for testing that component.

Factory methods promote encapsulation. In our example each of the inviters have the same functionality to retrieving a contact list from the provider, but implement it differently.

interface Inviter
{
  public function getContacts();
}

class GmailInviter implements Inviter
{
  public function getContacts()
  {
    // code to get contacts
    return $contacts;
  }
}

class HotmailInviter implements Inviter
{
  public function getContacts()
  // ...
}

Now you can add the factory pattern to your programming tool belt. Note, this is just example code, real code has comments and error checking.

Hi my name is Mark Deepwell and I’m a software developer at Thirdi Software. This post is the first in a series about building quality software. At Thirdi, we love quality and we love building things right because it means we can be proud of our work and our clients can have an awesome product. Let’s start.

Symfony check is a great website with a list of items that should be checked off before any Symfony based web application is launched. Doing those items will make the website more secure, have a better customer facing design, and be ready to log errors.

http://symfony-check.org/

Technical debt is when a software developer builds something in a ‘hackish’ way. A quick a dirty way that while works, makes the software more fragile, prone to bugs, and harder to maintain.

Technical debt is taken on when a project absolutely must be completed by a certain deadline.

But like financial debt it also comes with a few negatives. The accumulated technical debt will slow down all future development of the project because of increased work required to fix bugs in the ‘hacked’ sections of code, maintain the existing code, and to work around it. In the financial world, these would be called ‘interest payments’.

Technical debt is analogous to financial debt.

If technical debt gets out of control, the project may be doomed to be in ‘almost ready but a few key bugs’ mode for a long long time.

It’s important to pay off the technical debt, and fix the bad design decisions when you can (just like it’s important to pay down financial debt).