IOC Containers and Unit

testing.
Purpose to demonstrate and promote the
utility of IOC Containers for improving
primarily unit testing coverage.
Secondarily class decoupling
and simplification.

vs
With container injection this is
straightforward.
With this approach, the top-level PM is usually instantiated in
the top level view. It may be a singleton to allow other parts of
the application, such as commands to access it as required.
The child PMs are then passed down manually into the child
views, as shown below:
We usually do it this way.
Finally improving on manual DI, not
replacing it.
<example:MyComponent ... >

<mx:Script>

[Bindable]
public var model:MyComponentPM;

</mx:Script>

<example:MyChildComponent model="{ model.

myChildComponentPM }" ... />

...

</example:MyComponent/>
 Manual Injection
mple:MyComponent ... >

Script>

able]
var model:MyComponentPM;

Script>

mple:MyChildComponent model="{ model.myChildComponentPM }" .

mple:MyComponent/>
Containers for Unit Testing

A Container makes it easy to do this:

Rather than this which often arises from
manual dependency injection.
These 'unit tests' are really functional tests the lines represent
the dependencies.
Debugging a writing true unit
tests is more straightforward
than...
Debugging Functional Tests

Nothing wrong with a few of them

done by developers.
What's the difference between all these
tests!

SEE!
http://www.javaranch.
com/journal/200603/EvilUnitTests
.html#toofunc
Why use containers - Agility!

A Container allows us to be more agile.

Starting TD development before a contract is defined and
stubDelegate is complete.

By creating smaller stubs that involve only units under test.

Our code may need refactoring to ensure this.
Containers - Isolation

This leads to a focus on true unit testing and less functional

testing that passes a stub delegate across the Cairngorm
sequence if there's a problem with the sequence we have a
problem with our method under test, by passing the
dependency manually.
Containers - Clarity

Config becomes a central repository of stubs for a particular

test case that other developers can easily be made aware of
and peruse rather than looking through test methods which is
where they are currently.
The Container - Formalises DI

One can look at a class and distinguish more easily between

depended on and composite objects - ones that live and die
with the class as opposed to those that live on (aggregate).
Container - decoupling

The container promotes decoupling.

Links see other document.