tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/16-best-testing-practice-property-vs-constructor-injectionRobotlegs: Discussion 2013-04-28T10:30:52Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-03T05:04:23Z2009-12-03T05:06:00ZBest testing practice: property vs constructor injection<div><p>Shaun has a good post about his general preference for property
injection on his blog.</p>
<p><a href=
"http://shaun.boyblack.co.za/blog/2009/05/01/constructor-injection-vs-setter-injection/">
http://shaun.boyblack.co.za/blog/2009/05/01/constructor-injection-v...</a></p>
<blockquote>
<p>Mediators, by their very nature, are the sketchiest parts of an
application: they are tightly coupled both to the application and
the view. Commands are coupled to the application. There is very
little need to make either of these actors “safe” or
“final”, and for flexibility it is wise to leave them
“convenient”.</p>
<p>Proxies [Models] and Services, however, should not be too
coupled to the application. They should be the “safest”
most “final” classes in the interests of loose coupling
and portability. I would start with setter injection and migrate to
constructor injection as those components mature.</p>
</blockquote></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-03T05:06:51Z2009-12-03T05:06:51ZBest testing practice: property vs constructor injection<div><p>Should also note that most of the examples were written prior to
the support for ctor in SwiftSuspenders.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-04T00:06:44Z2009-12-04T00:06:44ZBest testing practice: property vs constructor injection<div><p>Thanks for that, a good read.<br>
It's hard to have an original thought around here.</p></div>Tim Oxleytag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-04T03:08:59Z2009-12-04T03:08:59ZBest testing practice: property vs constructor injection<div><p>A benefit of property injection with regards to Robotlegs, is
you don't have to do ridiculous stuff if you need a named
dependency which just happens to be the last constructor
parameter:</p>
<p>[Inject(name="", name="", name="", name="",
name="alertParent")]</p>
<p>So including this and all of the setting that needs to be done
in the constructor, there really is a lot of boilerplate code,
increasing potential for error.<br></p>
<p>You also don't have to work around the bug in the flash player
that means <a href=
"http://github.com/tschneidereit/SwiftSuspenders">SwiftSuspenders</a>
has to create one throwaway version of the object in order to
access its properties. Hm.</p>
<p>I think I will go with Shaun's hybrid concept where I use
property injection while sketching components together and on the
'business' tier, and constructor injection in the model &
mature classes.</p></div>Tim Oxleytag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-04T10:17:17Z2009-12-04T10:17:17ZBest testing practice: property vs constructor injection<div><p>Hey Tim,</p>
<p>thanks for writing about the problems with ctor injection. I'm
also<br>
bothered by the boilerplate, so I'm curious: Do you think it'd
be<br>
better to include the arguments position in the name parameters<br>
instead of making them an ordered list? I guess I could add
support<br>
for that to SwiftSuspenders without breaking the current system.
(No<br>
promises, though!)</p>
<p>Under that proposal, it'd also be possible to use<br>
[Inject(name4='alertParent')] iff no unnumbered "name" argument is
given.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-05T02:38:26Z2009-12-05T02:38:26ZBest testing practice: property vs constructor injection<div><p>Till,</p>
<p>Sounds great.</p>
<p>Thinking out loud, some alternatives to possibly make it read a
little clearer:</p>
<p>a dot or some character between the name and the position<br>
[Inject(name.3="alertParent", name.5="cthulhu")] etc</p>
<p>or perhaps name, position pairs<br>
[Inject(name="alertParent", position="3" ,name="cthulhu",
position="5")] etc</p>
<p>The former probably better though. Whatever way you decide,
explicitly stating the position will definitely help clean things
up :)</p></div>Tim Oxleytag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-07T14:21:42Z2009-12-07T14:21:42ZBest testing practice: property vs constructor injection<div><p>Hi Tim,</p>
<p>Regarding your original question: One way to ensure that your
dependencies are satisfied when using property injection is to
create an injector in your tests and call
injector.injectInto(instanceUnderTesr) or even
injector.instantiate(ClassUnderTest) during setup. That way an
Error will be thrown if any dependencies are unsatisfied.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6676812009-12-07T15:01:11Z2009-12-07T15:01:11ZBest testing practice: property vs constructor injection<div><p>I'm going to mark this issue as Resolved, but if you feel it
hasn't been properly addressed, please feel free to re-open it.</p></div>Shaun Smith