Eamonn Faherty

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
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.

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.

Hey ho!

I have been pretty busy getting ready for my lfpug talk next month. It is my first public talk at a user group and I am a little nervous! I am sure a few drinks will help me through it. I have my own page on their site too. Check it out!

I have been reading my Refactoring to Patterns book. After reading through it, Reafactoring and Design Patterns I am longing to work on a new project! Where I can put all of this good reading into use!

I have been pretty busy looking at what is going on in the world too. I am looking for a meaty project to get involved in:

I spoke to a couple of the maintainers of flexcover and they have agreed to add me as a contributor for it. I have a patch to submit but I am struggling with setting up my environment. I need to run my unit tests and build the project before I can commit.

I am also really interested in getting involved with some open social projects. There is a pretty mature AS3 api on google code. I am interested in taking that further and getting a really bullet proof setup! But, I cannot say much incase somebody steals my plans! Muhahahaha!

I am pleased to read that some people are using my pligg oauth integration hack. I am thinking about moving it over to google code. There were a few teething problems with my initial release but i think it is okay now!

And finally, and most importantly! I have been preparing for my wedding. We had a tasting a couple of weeks ago which went well! We now have the suits! And the flower girls outfits! I am having my stag on Friday, so dont expect any updates around then!! The only thing left really is sorting out our new home which seems to be going well!

Hey,

I haven’t blogged for some time. I will be more active from now on (I have said that before). I have been busy planning our wedding and we are buying a house. We have been approved by the bank and we just have to sit tight and wait to do all the legal stuff.

I have been busy in the actionscript world too. I have been using asaxb and am loving it! I have also put my name down to do a talk at lfpug in October (wish me luck for that). I may post a preview here before hand. I have left my checkstyleas3 project as the almighty Joa Ebert has beat me to it. I was trying to use the flex sdk compiler modifying the asdoc configuration but he has been more successful! I think he used antlr.

I am now onto other things. I have started up a site called flashthings. I used Pligg CMS to generate the site and wrote my own Twitter login. I will post this mode soon! Here I am going to be posting peoples work that I feel are good and linking to projects that I have come across. Feel free to sign up and add some stuff too! Here I also want to build up a list of meetups in the flash world so watch that space! I also have a page which watches twitter for flash activity and posts what is going on. Beware it is unfiltered! Ha Ha.

Oh well! That is it for now. I will post more very soon!

I have been thinking a lot recently about the value of unit testing, doing TDD and coverage. I remember ignoring advise that test coverage was not a silver bullet. I remember reading articles explaining why but I have to admit I did not listen as much as I should have. I kept remembering a difficult code base I had to use that was unit tested whishing it was tested thinking that it would solve all my problems.

I now think a little differently. The problems I face most are broken windows and software rot. It the java world people seem to invest in code using unit tests and integration tests. This is a new philosophy in the actionscript world. Some people have embrassed this change but most haven’t. I used to think this was a bad thing but now I am unsure. I think investment in code is what really keeps it good. Developers need to buy into the code base, value it and want it to suceed. Having a high test coverge helps this but does not promote it for flash developers. This needs to be an visual thing. This is how flash developers tick. I will post more when (if) I know more.

My other point is that I am resuming my open source work more agressively than ever. Expect a good release soon!!

I have recently discovered the wealth of information available at the Adobe devnet site.

I have been reading about the options surrounding video. I never took an interest in video when it first starting taking off so I was a little left behind. I decided to have a google for help and found some amazing resources on the devnet site. There are articles about the recording of material, the types and options for encoding and the different mechanisms of distribution.

Thank you Adobe.

This is inspired by the view from my window.  I want to build up a full, interactive, 3d model of a council estate.  I am learning Papervision and so this stuff is slow and rough around the edges!

You can move the mouse left and right to rotate the building and you can use the arrow keys to move the camera around.