Actionscript3 Tdd A Little More Terminology

Title: Actionscript3 TDD: A Little More Terminology Date: 2009-11-22 20:00 Author: eamonnfaherty Category: testing Tags: Actionscript, flashtdd, tdd Slug: actionscript3-tdd-a-little-more-terminology

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

Published: November 22 2009

  • category:
  • tags:
blog comments powered by Disqus