PureMVC Architects Lounge

Hi.

I've struck a problem today, which I suspect is indicitive of a problem in my design....but I'm not sure how to proceed....

I have a mediator which does something invokes a method on an object.  The object does it's business asyncronously, and dispatches an event once it's complete.

The mediator listens for this event, and -- when appropriate, sends a notification out to the rest of the application.

I want to write a test which invokes the behaviour on the object (via the mediator) and waits for the notification being dispatched from the mediator.  At this point we can interrogate the mediator to make sure that the operation has completed as expected, and the mediator is correctly consuming my object.

But, I don't see how to write this test.  The main problem is that a mediator doesn't expose it's notifier as a property through composition, instead it's coupled to using the facade.

I really don't want my tests relying on a facade, primarily because it's a singleton, and therefore is likely to generate dependancies between tests.

A potential solution I see is to modfiy the Mediator take a Notifier, rather than extend Notifier.  (composition).  However, this seems like a big change, and ... the very fact that I'm looking at having to modfiy the source of PureMVC probably means that I've missed something somewhere along the line.  (Ie., it's probably a fault with my design, rather than PureMVC).

Can someone please offer some suggestions here?

cheers

Marty

Use a mock object in place of your view component, that exposes the same method and simulates the async behavior.

Also, you can't really test sendNotification without testing the Facade, and other actors since the Facade is the method by which Notifiers send notifications, and it does so via the View. True, if the Mediator's INotifier interface were implemented by composition and not inheritance, then you could replace it with an INotifier mock implementation for the test. This would have implications in MultiCore as well, so I'll reserve the consideration of this for a time when I can look at the whole issue. That and the idea of having a destroy method on Facade, Model, View and Controller are ideas that could help out quite a bit in unit testing.

For now, if you look at the PureMVC unit tests, you'll see that the simplest classes and the methods of each class that are testable outside the framework go first, and then the tests proceed into actor interdependent tests, and care has to be taken to anticipate the behavior of the framework and build tests in such a way as to remove impact of the singletons on the testing process. This happens by naming cached objects from tests differently, performing cleanup to remove the objects after the test, etc.

The progression of tests dosen't depend upon earlier tests (that is setting data in one test and expecting it to be there in the next), but do accept that passed features can be used without assertion in subsequent tests.

-=Cliff>