Re: DI Through Constructors w/Wicket

2013-07-01 Thread Martin Grigorov
Hi,


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




Re: DI Through Constructors w/Wicket

2013-07-01 Thread uwe schaefer

On 06/29/2013 03:13 PM, William Speirs wrote:


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.


maybe it makes it worse in your perspective, but yuo might want to have 
a look at jukito.


https://code.google.com/p/jukito/

at least it makes it easy to combine mockitoguice

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DI Through Constructors w/Wicket

2013-07-01 Thread William Speirs
There are a few of these libraries to make running Guice in JUnit easier,
Onami is another: http://onami.apache.org/test/

However, if you have to add all of this extra stuff to your unit test, is
it really worth it?

Still struggling with all of this... but starting to hone in on my
project's best practices.

Bill-


On Mon, Jul 1, 2013 at 12:44 PM, uwe schaefer u...@codesmell.de wrote:

 On 06/29/2013 03:13 PM, William Speirs wrote:

  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.


 maybe it makes it worse in your perspective, but yuo might want to have a
 look at jukito.

 https://code.google.com/p/**jukito/ https://code.google.com/p/jukito/

 at least it makes it easy to combine mockitoguice

 cu uwe


 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: DI Through Constructors w/Wicket

2013-06-30 Thread uwe schaefer

On 06/29/2013 03:13 PM, William Speirs wrote:


Hi Bill,

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.


me too. well, normally.
i came to the idea, that UI-Tests are not stricly unit-tests in most of 
the cases anyway, so i'd consinder this rule to be in the depends-area.


anyway, what you could do is to have constructor-injection for your 
tests while using the guice-provided at runtime. on the other hand,

you certainly dont want have this in your code everywhere:

new LinkVoid(link,someServiceInstance){...}

as this makes you code hard to change.
if you'd test the Link in isolation that'd be perfect, but given this 
link is in a panel, in a panel, in a panel, in a panel of your page, 
dependency passing becomes ridiculous...



Am I totally wrong here? Am I missing something? I'd love people's
feedback on this!


stomach feeling: i am with you avoiding guice in unit tests. for 
wicket-tests it is hard, and pollutes the production code more than it 
helps, imho.


cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DI Through Constructors w/Wicket

2013-06-29 Thread William Speirs
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.

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



Re: DI Through Constructors w/Wicket

2013-06-26 Thread Martin Grigorov
Hi,


On Wed, Jun 26, 2013 at 4:14 AM, 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


Don't be sceptic ;-)

Here is some code that has been used with Wicket 1.4 -
https://github.com/jolira/wicket-guicier.
You can use it or at least be inspired by it.


 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


The first thing I'd try is to use custom IPageFactory.


 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




Re: DI Through Constructors w/Wicket

2013-06-26 Thread Daniel Watrous
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




DI Through Constructors w/Wicket

2013-06-25 Thread William Speirs
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