Unit testing with PureMVC: recreating the singletons for each test

[DavidArno]

I have been experimenting with unit testing with PureMVC. Two problems I encountered were:

1. Since PureMVC is singleton-based, I cannot destroy the entire PureMVC framework between tests. I have checked this website, but there doesn't seem to be a testing framework that addresses this.
2. There doesn't seem to be a mocking framework for PureMVC, so proxy, command and mediator mocks have to be written from scratch.

I looked into two possible ways of addressing the first issue:

1. Devise a way of ensuring that the MVC destroyed all references to mediators, proxies and commands between tests.
2. Create a new instance of the MVC for each test.

I decided that the first approach was too unreliable as it still left the facade and MVC classes hanging around between tests and they still might have state data that could affect future tests. I have therefore been experimenting with Flex Unit-based framework that destroys the singletons and creates new instances of them between tests, and with creating some mock classes.

Before going too far down this path though, I wanted to check whether I'd missed anything blindingly obvious. Does PureMVC already have such frameworks that I have missed? Does PureMVC already have some way of fully resetting its state between unit tests?

If not, I'd like to develop the ideas into a proper framework and publish it. Is there a way of getting approval from the PureMVC team/ community for this?

Thanks to anyone listening,
David Arno.

[Tekool]

If you use the PureMVC multicore version you can create and remove a Facade :

Code:

public function testAdd():void
{
var data:ArrayCollection = new ArrayCollection([]);
var proxy:MyProxy = new MyProxy( 'UnitTestProxy', data );

var facade:IFacade = Facade.getInstance( "FacadeName" );
facade.registerProxy( proxy );

var item:MyClass = new MyClass('0123456789');
proxy.add( item );

assertTrue
(
"Expecting proxy.containsValue( item ) == true",
proxy.containsValue( item )
);

Facade.removeCore( "FacadeName" );
}

Upgrading from PureMVC single-core to PureMVC multi-core only take 5 minutes.

But you're probably right, a method to deference the instance in the single core Facade is probably a good idea.

[puremvc]

Moving to MultiCore is the answer, as Fredric mentioned. Just create a new core for each test and everything will be fine.

Also, I happen know that Richard Szalay, author of the ASMock framework (http://asmock.sourceforge.net/) has put together a three part tutorial on using it with PureMVC, and it should be out shortly, including with test suites of increasing complexity. It is based on the Cafe Townsend example, ported to MultiCore. You might want to contact him through his project if you need info right away about his results and experiences mocking with PureMVC.

-=Cliff>

[DavidArno]

@Tek,
I didn't realise it was so easy to switch a single core project to a multi-core one. This may well be a better solution. However the single core solution has the advantage that there can only be one MVC instance. I like the idea of applying this restriction to a project unless it must import "modules" that need their own MVCs.

@puremvc
Thanks for the tip off re Richard Szalay's work. I have contacted Richard to see whether he has already covered the type of mocks I've been working on.

I may well shelve my project on the strength of what you have both told me. If not, I'll post details of it as and when I finish it.

Thanks,
David Arno.

[puremvc]

I agree with your thoughts on the merits of the 'single core' Standard version. That was the entire reason that singletons were implemented to begin with, and is still one I stand behind.

When Flex got Modules, there was a clamor for a solution to the problem and rather than drop the Singletons, Multitons were the logical extension of the principle.

If you're doing a small single core app, don't expect it to go modular in its lifetime, and don't have time for unit testing (this probably represents the majority of Flex apps being deployed), then Standard Version is fine for you. If you ever need to go to MultiCore, or write unit tests, it's a straightforward migration.

But if you suspect you could go modular at some point or plan to do unit tests, I suggest starting with MultiCore, and minding your app's use case implementations so that you don't end up spawning cores that aren't needed (hard to do, since the name of the core can simply be a constant, and you only call getInstance once as your app is bootstrapping, passing in this core name).

-=Cliff>