@All in @Provides methods

[Przemyslaw Galazka]

Hi,

Do you have an idea how to implements in Jukito a following feature...

@All in @Provides methods. 

example:

public class CalculatorTestModule extends JukitoModule {


@Provides
Calculator createCalculator(@All Display display) {
return new Calculator(display);
}


@Override
protected void configureTest() {
bindManyInstances(Display.class,
new BlackDisplay(),
new RedDisplay());
}

When installing this kind of module I expect to have all test methods run twice. First when test fixture is setup using BlackDisplay and second when using  RedDisplay in binding context.

Any idea is welcome :)

Cheers,
Przemek

[Christian Goudreau]

That is something I have never tried! You're really pushing the limits :D

Isn't all supposed to be used in a test!?

--
You received this message because you are subscribed to the Google Groups "Jukito" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jukito+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Christian Goudreau

www.arcbees.com

[Przemyslaw Galazka]

@All annotation is cool but when I am using  dedicated  modules it will not work as guice context is build before injections to test method occur.

I found this problem when testing using for example:  install(new DefaultTestModule());

Lets say that DefaultTestModule have defined incomplete guice context config. Every test if using this module should provide this lacking config.

For example 

  @Provides

  Button mockButton() {

    return new MockButtonImpl();

  }

So in test context we have only one implementation bound for Button interface. What if I want run the same test but for different implementations of Button ?

JukitoRunner is based on ONE injector. If this runner could operate on more injectors and for every one run all test that would sort out the problem :)

What do you think ?

xx
Przemek Gałązka

[Christian Goudreau]

In that case, you should use @Named to bind several implementation.

[Przemyslaw Galazka]

Really ? Come on ;-) it is not that simple. Look what I wrote about guice context building.

[Christian Goudreau]

Nah you're right :D If it was that simple you would have already resolve that problem.

I always design my apps to have one and only one Ginjectors. Having more than one seems a little bit weird to me. I also can see that it will become a maintenance hell as it will become harder to find what is the root of a problem (GinjectorA or GinjectorB?) as well as what is bound to what.

I'm wondering, it seems like we want to had a behavior to Guice that isn't existing (@Provides with @All). I don't think it's a good idea to do that since we should rely on the already existing knowledge that the user have of Google Guice. On the other hand @All in test affects the runner which is a feature given by Jukito to enhance efficiency.

That being said, I don't think I'm helping you at all :D I just never ran into this and I'm a little bit loss as to how to do this cleanly in regards to my previous comments

[Philippe Beaudoin]

An idea I had that wouldn't be too hard to do would be to allow multiple JukitoModule as innerclasses in the same test class. Jukito would then run the test suite multiple times with a different module each time. This shouldn't be to hard to implement and I believe it would solve your problem.

You should already be able to simulate that today by putting all your tests in a base class and having two derived classes, each with its own JukitoModule.

Cheers,

   Philippe

[Przemyslaw Galazka]

Thanks Philippe,

for now, when I analyzed JukitoRunner I found that this runner support only one inner class with JukitoModule and it is using one Injector. Thus I have got expected bahavior using derived classes.

But @All feature is very cool and I think that runner should create as many Injectors and sets of tests methods  as many inner jukito modules developer will include.

@Christian,

One injector in production code is normal case and good pattern. But tests should have this cool feature to run in various environments.

Please imagine that you have base code which is used in few projects. You would want to test SUT and verify behaviour  of it Collaborators in ONE test, even though some of collaborators have its specific implementation per project. 

Pozdrawiam
Przemek Gałązka

[Christian Goudreau]

But tests should have this cool feature to run in various environments.

I agree with you that it would be awesome to test various environments :D

Nice thinking Phil! 

[Przemyslaw Galazka]

Guys,

Today I found out that guice support multibinding. My use case with different environments could be resolved by subclassing BUT I wonder if  mulitbindings could help somehow.

https://code.google.com/p/google-guice/wiki/Multibindings

Of course there is still option for multi injectors. I can start a branch with proposal but that going to be revolutions in JukitoRunner. What do you think ? 

[Przemyslaw Galazka]

https://github.com/przemekgalazka/Jukito/commit/af43f13f4dd51ec5868013ed759b1ce1b19d4db0

[Christian Goudreau]

Would be great to support this actually, if you want to try to give it a shot, you're welcome to! :D