Scribd
Upload
5 views17 pages

Enhancing Unit Testing with IOC Containers

The document discusses using IOC containers to improve unit testing by allowing easier injection of dependencies. Containers formalize dependency injection and promote decoupling. They allow code to be developed and tested in smaller units before full implementation. This leads to clearer, more isolated and agile unit tests compared to manual dependency injection and functional tests.

Uploaded by

davorian
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views17 pages

Enhancing Unit Testing with IOC Containers

The document discusses using IOC containers to improve unit testing by allowing easier injection of dependencies. Containers formalize dependency injection and promote decoupling. They allow code to be developed and tested in smaller units before full implementation. This leads to clearer, more isolated and agile unit tests compared to manual dependency injection and functional tests.

Uploaded by

davorian
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

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="{ [Link] }" .

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!
[Link]
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.

You might also like