What is unit testing
Unit tests are methods that run in order to verify the output of a method is what is expected when given a predefined input. This is useful as you can check if your code does what it should. There is a whole world of information on this on the internet. Check out test driven development.

History
There used to be a few different unit testing frameworks – flexunit, fluint and asunit. asunit was the fastest to run but has not been too popular. I am not sure why. Fluint was a flex-centric testing framework with stuff like ui impersonator (mocking). Flexunit was the most used.

Current
Flexunit was taken on (again) by Adobe and merged with fluint. After adobe took it on again they named it version 4, probably to bring versioning inline with Flash Builder and flex. with this change they improved the API to introduce metadata for methods so that they are run before, after and as test methods. It is now distributed with hamcrest (same as the java hamcrest library) and a number of runners and listeners. It is the most used and it is the one i would recommend.

How it works
You write the unit test in any of the supported styles (flexunit 1, flexunit 4 or fluent or maybe even in another style) and you mark them to run with the associated runner (using metadata). You then run the tests using that test runner. Whilst the test runs a listener is also run. There are multiple test listeners, they are for different environments – to be run on a ci box, in the browser, in the IDE etc.

Continuous Integration
You cannot currently run unit tests without a flash player. You cannot currently run a flash player without a virtual frame buffer (think that is the term) or without a window manager running. With hudson (or jenkins now) you can install and run the vnc plugin, this has been the easiest way I have found so far. This takes care of all that stuff for you. It even deals with multiple vnc sessions at the same time if you have more than one hudson executor at a time.

Coverage and static analysis
You can get coverage from running flexcover and there is a flex pmd library released by adobe – there is the usual pmd offering and a cpd plugin.

How to run it all
you can run it all using maven (using the flexmojo stuff) or you can roll out your own ant stuff. Rolling out your own ant stuff is the way to go if you have a complicated dependencies system (like at my last job), otherwise if you just want to get the job done maven is probably the way to go.

I will attach a working example project tomorrow.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.