Eamonn Faherty

I have been using Google Apps for over a year and I love the service.

[Email]
In the past year I have had about 20mins of downtime which is less than a third of the downtime I had when I paid for hosting. The service includes great spam filtering, good message labeling, secure imap and pop3 and webmail. The service is fast and very reliable. It is much better than squirrelmail.

[Sites]
I used Google Sites to host a website for our wedding. It was inbetween using a template service like RV Site Builder and a wiki. It was easy to assemble and looked pretty good. It has built in Google Analytics tracking support so that you do not need to edit any templates.

more to come…
More info and sign up

I am heading off to IGE today. IGE is:

The most influential group of gaming industry speakers ever assembled at a b2b exhibition will feature at the IGE Gaming Leaders Programme of presentations, seminars and round table discussions. The three day programme, consisting of 50 sessions with more content being added up until the shows open, will deliver a unique insight and crucial first-mover advantage across a range of important commercial, technological, legislative and social responsibility areas

I am going to be checking out all of the offline slot games and some of the online ones too. I have heard that there is a lot of innovation in bingo this year and after the improvement in offline slots last year I cannot wait to see what is there this year. I will take some pictures about blog them this week along with some reviews.

On a side note: if you want to meet with me to discuss some opportunities then drop me an email using the contact form. I will be checking my email whilst there.

This is the last blog post I plan to make about the terminology around TDD. There will be real life examples from now on.
I have previously discussed the terms collaborators, subject under test (SUT) and test doubles. Here, I am going to describe the three types of test doubles you can use.

The Real Thing
If you have a simple collaborator which only really stores and retrieves values, like a model, then is it worth replacing it for testing purposes? I personally think as long as this collaborator is unit tested then it is okay. Once there is some logic in the collaborator, some mutator methods, then I think you must refactor your unit tests and use a proper test double.

Stubs
Stubs are replacements for collaborators with pre-programmed responses for requests and fields that store inputs:

public function get username():String {
    return "eamonn";
}
public function set username(username:String):void {
    _usernameSetDuringTest = username;
}

The first method does two important things. It makes your code deterministic. Your collaborator will always return “eamonn” as a username. It also means that the only complicated thing is your subject under test. Both of these things are very important for unit testing code.
The second method stores the input sent to the object. The field _usernameSetDuringTest can be queried later to find out if the test should pass or fail.

Mocks
Mocks are objects setup to expect interactions. When you use a mock you define which methods on it should be called and which parameters it expects. You run your test code and then you verify that the mock has been interacted with in the way you thought it should have been.

My Thoughts
From my experience I have found mocks to be very frustrating. Unit tests that use mocks are more tightly coupled to the production code and this makes refactoring harder.
If I rename the method in the example above I have the following changes:
If using a mock, I would change the name of the method in the real collaborator, the test double and in the unit test as it would be listed as a method that should be called.
or
If using a stub, I would change the name of the method in the real collaborator and in the test double
If I am using FDT and these two classes implement the same interface I can use the refactor -> rename method tool within FDT. This handles the rename when using a stub. It cannot currently handle the change if I had used a mock.
This might seem like a lazy reason to use a stub over a mock but you will have to consider when you will be making this change. It will probably be a very high priority bug fix needed a year after you wrote the code and you will probably want to get it resolved ASAP. There are many other reasons to use stubs over mocks but I think you should make that decision with your team or for yourself. Here is a really good article on the differences between mocks and stubs. It also spiders onto other good articles on other testing approaches. It is definitely worth checking out if you have the time.

I have been posting about design patterns recently and I am realizing that it would be useful to post about Test Driven Development too.

As a gentle introduction I am going to go through some of the vocabulary.

Test Driven Development is the process; Red, Green, Refactor. That is the easy way to remember it. Below is your workflow:

1) Write a unit test. A unit test is a method that tests another method. The test calls the method that you are testing and verifies that the response is as expected. Your unit test should always use the same inputs and should always expect the same response. The class containing the method you are testing is called your subject under test (SUT).

public function testAddingTwoNumbers():void {
    var result:int = sut.add(2,3);
    assertEquals(5, result);
}

2) Run your unit test. It should fail. This feels kind of silly but this is the best (easiest) way to check that the test is being run. This is the RED stage.

3) Write some source code that makes the test pass. This should simple literal values. Run your test and it should pass. This is the GREEN stage. This also feels silly but it proves your test passes before you add the complex logic in there.

public function add(valueOne:int, valueTwo:int):int {
    return 5;
}

4) This is now where you refactor. You take steps to make your design better. It is up to you how far to take the refactoring. In this example I would change the method to the following:

public function add(valueOne:int, valueTwo:int):int {
    return valueOne + valueTwo;
}

The example above was trivial. The add method does not use any other objects. If it did the correct name for those objects would be a collaborator. When you are TDD’ing you should replace collaborators with simple objects that return simple values. These are referred to as test doubles, after the term stunt double. You can use patterns such as the IOC pattern and Factory patterns to make it easier to replace collaborators with test doubles. That is coming in post 2!

Background Reading
The creation method pattern

The Problem?
You want to use objects that are created else where and are of a set type but the implementations may vary.

Examples?
SocketManager, or any thing that needs to be replace during unit testing.

How?
The constructor of my complex object:

public class CharacterFactory {

	public static var factory : NonPlayerCharacterFactory;

	public static function getAPlayer() : IPlayer {
		return factory.getAButton();
	}
}

The using of the creation method:

var player:IPlayer = CharacterFactory. getAPlayer();

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• You can get objects without knowing how they are created or where they come from.
• You can share objects without the users of the factory knowing the objects are shared.

Why is it bad?
• It is confusing to read code where objects are not being created directly.
• Debugging is hard, as you have to know what was in the factory when you used it in order to know what object you have.

Further Reading
Read about the IOC pattern.

More
Factories are great! They allow you to define scope for your application. This means that you can set a testing scope when you are running unit tests. The involves setting the factories used in your factory to a test factory which provides test doubles. Changing the scope of the factories outside of your application means that you test your code without making any special changes.

Background Reading
The factory method pattern

The Problem?
You have a complex object, which has a lot of arguments in its constructor or you always want to construct the object using different sets of parameters.

Examples?
Socket Manager

How?
The constructor of my complex object:

public function ComplicatedButton(colour:uint, mouseOverColour:uint, mouseOutColour:uint) {
	_mouseOverColour = mouseOverColour;
	_mouseOutColour = mouseOutColour;
	setUpGraphics(colour);
addEventListeners();
}

The using of the creation method:

var redButton : ComplicatedButton = ComplicatedButton.getRedButton();
var blueButton : ComplicatedButton = ComplicatedButton.getBlueButton();

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• Anyone using one of the creation methods to create the object is guaranteed to have an object in an identical state as the other users of the method.
• Objects that complicated or a lot of constructor parameters can be simplified.

Why is it bad?
• The class now has two responsibilities, the main purpose of the class plus the instantiation of its instances.
• The class can often grow in size as the creators in declared inside the class. This makes the class harder to read for a developer.

Further Reading
Read about the factory patterns.

More
Creation methods are a great first move towards using factories. Their concept is easy to grasp and doesn’t require much extra code. The class can grow quite big, quite quickly but it is up to you to spot when the acceptable size has been passed for you to put your refactoring hat on. I would use them when I have a graphical component that accepts integer colours as parameters or when I have components that need a lot of initial set up. In the example above I have colours specified as integers. To ensure that all of the buttons considered to be red or blue are the same shades of red or blue I protect users of my ComplicatedButton by adding creation methods with the colours hard coded. Once I have more than one group of setups I would refactor, replacing the creation method with a factory method.

Background Reading
Read about the singleton

The Problem?
You want to have multiple instances of a singleton and want global access to them all. This may be because the objects use groups of resources, such as different groups of sounds, or because the objects need a lot of configuration, such as currency converters, or need global access, an event dispatcher.

Examples?
Currency converter, sound controller, global event dispatcher

How?
The Multiton:

public class SocketManagerMultiton {
	private static var _instaces : Dictionary;
	public static const CHAT : String = "CHAT";
	public static const WEATHER : String = "WEATHER";

	public static function getInstace(instance:String) : SocketManagerMultiton {
	ensureInstanceExists(instance);
		return _instaces[instance];
	}

private static function ensureInstanceExists(instance:String) : void {
		if (_instaces == null) {
			_instaces = new Dictionary();
		}
		if (_instaces[instance] == null) {
			_instaces[instance] = new SocketManagerMultiton();
		}
	}

	public function send(message : String) : void {
	}
}

Example Use:

var chatSocket : SocketManagerMultiton = SocketManagerMultiton.getInstace(SocketManagerMultiton.CHAT);
chatSocket.send("hello world");

var weatherSocket : SocketManagerMultiton = SocketManagerMultiton.getInstace(SocketManagerMultiton.WEATHER);
weatherSocket.send("HOW_IS_THE_WEATHER");

Why is it good?
• It is easy to understand; it is a simple pattern that needs little extra code. It builds on the singleton pattern, which is well known.
• See singleton pattern for other good points.

Why is it bad?
• It tightly couples the classes that use the multiton to the fact that they are using a multiton.
• See singleton pattern for other bad points.

Further Reading
Read about the factory and inversion of control patterns.

More
Multitons are a way of grouping Singletons. They share the benefits and carry the problems that Singletons have. They are good for classes that use a lot of resources such as socket connections or classes that cache things. They do make code harder to refactor and very difficult to unit test but if follow the suggestions I made in the Singleton post then you can limit your pain, a bit anyway! If you are going to use a multiton make sure you use String constants as I did above. It is easy to make typing mistakes when using String literals. Also the constants can be meaningful, as they are in my example.

Background Reading
None

The Problem?
You want to ensure you have only a single instance of an object and want global access to it. This may be because the object uses a resource, such as sounds, or because the object needs a lot of configuration, such as a currency formatter, or needs global access, an event dispatcher.

Examples?
Currency formatter, sound controller, global event dispatcher

How?
The Singleton:

package singletonpattern {

	/**
	 * @author eamonn faherty
	 */
	public class SocketManagerSingleton {
		private static var _instace : SocketManagerSingleton;

		public static function getInstace() : SocketManagerSingleton {
			ensureInstanceExists();
			return _instace;
		}

		private static function ensureInstanceExists() : void {
			if (_instace == null) {
				_instace = new SocketManagerSingleton();
			}
		}

		public function send(message : String) : void {
		}
	}
}

Example Usage:

package singletonpattern {
	import common.Example;		

	/**
	 * @author eamonn faherty
	 */
	public class SingletonPatternExample extends Example {

		public function SingletonPatternExample() {
			var socket : SocketManagerSingleton = SocketManagerSingleton.getInstace();

			socket.send("Hello world");
		}
	}
}

Why is it good?
• It works well; if you use an instance protector then you can be sure that only a single instance will exist.
• It is well understood; it is widely used in the actionscript world.
• It is easy to understand; it is a simple pattern that needs little extra code.
• It is easy to implement; actionscript allows us to check the caller of a method and allows us to use private classes.

Why is it bad?
• It tightly couples the classes that use the singleton to the fact that they are using a singleton.
• It is not possible to extend the singleton class if you wanted to add functionality.
• You cannot use your singleton class again; you cannot extend it or reuse it with composition.
• If you are unit testing a class that uses a singleton you need to add some code to your singleton to make testing possible.

Further Reading
Read about the factory and inversion of control patterns.

I recently did my first public talk! It was at LFPUG (London Flash Platform UserGroup).

Here are the details

I think it went really well. I had some very kind feedback via email and twitter and also on the night in person!

A few people have requested that I upload the examples I used and the slides so here they are.

Over the next few weeks I am going to be posting example patterns with more information, in more depth than I did on the night.

If you want me to cover a pattern please post a comment with the pattern name and I will bump it up in the list.

I am now a married man! It was a great day and we had a couple of days away to celebrate. Thank you to everyone who came! I will post pics, vids and some more info soon!