On Sat, Jun 29, 2013 at 4:13 PM, William Speirs <wspe...@apache.org> wrote:

> I'm just getting to this now... weekend coder.
> @MartinGrigorov - this looks exactly like what I want, or parts of it
> at least... I'll certainly check it out. And you're right, I shouldn't
> be so skeptical, you Wicket folks seem to always come through with
> some library when I ask a question :-)
> @DanielWatrous - your blog is helpful, except that you instantiate a
> Guice instance in your unit test. I'm still wrestling with what I
> consider "best practices" with respect to Guice/DI and Unit Tests, but
> I'm strongly leaning towards the best practice of: If you're having to
> create an injector in your unit test, then you're doing it wrong.

I cannot say that.
WicketTester tests are not exactly unit tests.

I use DI in my tests all the time. I just try to create as minimal
applicationContent (Spring) as possible for a given test. There is no need
to bind all services when just one or two are used in the tests.

For me it is more wrong to the testing to drive the architecture of the
main functionality.
When developing the main functionality you should think how to make it
reusable. The first time when you reuse some functionality is in the tests.
When you have a second use case where you need to use this
component/service/... then you will see how good you made it before. If you
need to refactor it then the tests will protect you from regressions for
your first use case, and you'll have to add tests for the second.
If it is easy to add your second use case and second test then your design
is good enough. If it is not then you should think harder.

> Dependencies should come in through the constructor and constructor
> only. In the unit test, mocked instances of those dependencies should
> be passed in through the constructor after you've called new to create
> the object itself. This ensures you're ONLY testing the object, and
> none of its dependencies in that unit test. If you cannot pass your
> dependencies through the constructor, it's most likely because you're
> not letting the framework create the instance for you, and this
> exposes a deficiency in your implementation. This is the problem with
> Wicket, it creates the pages for you (unless you implement your own
> IPageFactory like in the library Martin linked), which forces you to
> use field injection like you did in your blog example.
> Draconian "best practice"? Maybe, but when working with a number of
> developers on a project, I find it best to keep strict but simple
> rules; even better when they can be enforced with things like
> Checkstyle.
> Am I totally wrong here? Am I missing something? I'd love people's
> feedback on this!
> Bill-
> On Tue, Jun 25, 2013 at 10:38 PM, Daniel Watrous <dwmaill...@gmail.com>
> wrote:
> > I worked out this process:
> > http://software.danielwatrous.com/wicket-guice-including-unittests/
> >
> > It enables unittests and may help you toward your goal.
> >
> > Daniel
> >
> >
> > On Tue, Jun 25, 2013 at 7:14 PM, William Speirs <wspe...@apache.org>
> wrote:
> >
> >> I think I know the answer before I ask, but is there any way to do
> >> constructor injection with Wicket? Say I have a web page and an email
> >> service. I need the email service in the web page. Now everyone is
> >> going to say, "Simply use field injection." That will work, but makes
> >> unit testing a real pain because now I have to setup injection for my
> >> unit test (or add additional methods to all of my pages so I can
> >> manually set these field, or additional constructors that set these
> >> fields). I should be able to unit test a class without needing
> >> injection, but instead passing mocks through the constructor.
> >>
> >> I feel like this is impossible in Wicket currently because the
> >> DefaultPageFactory is using reflection to create the page instances
> >> instead of the injector (Guice in my case). It would be easy enough to
> >> get the injector and call getInstance() to obtain a page instance. The
> >> problem is when you need to pass in parameters. There is no concept of
> >> parameters for a page other than what is passed via the constructor,
> >> so you cannot call something like setPageParameters because it doesn't
> >> exist. If using Guice, you could create an @Assisted injection, and
> >> have a factory.
> >>
> >> Has anyone tried creating this type of IPageFactory -- a
> >> GuicePageFactory? What kind of pitfalls would exist if I attempted
> >> such a thing? Am I being stupid and missing something? Thoughts?
> >>
> >> Thanks...
> >>
> >> Bill-
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to