Module, Test and Mock

[Maatary Okouya]

Hi,

I'd like to be able to insert some mocks in the creation of some of my service for test purpose. Based on the following answer http://stackoverflow.com/questions/483087/overriding-binding-in-guice/531110#531110  on stackOverflow i have the following question:

>>>but if you're writing unit tests, you probably shouldn't be using an injector and rather be injecting mock or fake objects by hand.>>> 

I do not understand that. The all idea of encapsulating creation is to keep it in one place (obviously separating usage from construction). If one inject by hand rather than by an injector, then if the constructor change you have a problem, you need to propagate that in all the test classes that do the creation by hand. Moreover if the constructor are made private as per the best practice recommended, that cause a problem too

Hence, my question here is what is the recommended approach to provide some mock in unit, that do not break the encapsulation of the creation. I do not keep test in the same package as the class. I do BDD. In my test i package by Feature. 

Best,

M

[Stephan Classen]

If you pass dependencies in you constructor which are not required for the test then your class has most likely too many responsibilities.
If all your dependencies are required for the test you have to adapt the test any ways and should not worry about the compiler errors but embrace them since they help you find all the test cases which need update.

I would still say it is best practice to have unit tests (not integration tests) avoid the usage of an injector.

If you want to use the guice injector in the tests I would recommend to use a testing framework like jukito.

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/b17f12f0-e141-49d4-850c-6d59630f4f1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Thursday, August 21, 2014 2:42:04 PM UTC+2, scl wrote:

If you pass dependencies in you constructor which are not required for the test then your class has most likely too many responsibilities.
If all your dependencies are required for the test you have to adapt the test any ways and should not worry about the compiler errors but embrace them since they help you find all the test cases which need update.

+1

Wrt the visibility of the constructors, because it's a generally accepted practice to put tests in the same package as the class under test, using a package-private constructor just works (you could annotate it with some @VisibleForTesting annotation if you still find that "too visible" and fear that some developer would use the constructor directly; with such annotation, or similar comment in the javadoc, you can later blame them for not following the rule ;-) )

[Maatary Okouya]

I use package by feature in my test source. I took it from BDD practices. I like it because it give you straight away the specification of your software. Specification that reflect what you software does and how does it do it. How to use your software. From my feature specification all the way down to my unit. I actually package by capabilities that the features realize. I adhere to the idea that, test are actually specification. So when i look at my code, i don't care about the implementation detail. I care about its capabilities, what it does. Hence i look are the feature that realize those capabilities; That is where i connect to the feature spec all the way down to the unit spec. but that is out of scope

In any case, why are you against using the module override functionality ? What is wrong with it?

--
You received this message because you are subscribed to a topic in the Google Groups "google-guice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-guice/12JI7LFFFJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-guice...@googlegroups.com.

To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/762ada39-ba7f-4eb7-8b36-6fac5104b46a%40googlegroups.com.

[Stephan Classen]

I dont think it is wrong to use it. But I don't see a need for it.

If you are unit testing then you want only those bindings in your injector which are required for the test. Hence no need to override anything.
If you are doing integration test then you want to have actual code executed and no mocks. Again no need to override anything.

But there is nothing wrong with the overriding capabilities in guice. They are fast and reliable. I personly just never used them for testing.

You received this message because you are subscribed to the Google Groups "google-guice" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.

To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAEqpkuv3pst2Hq4HAFL-Y0sMpneMMmeK12vJrd71cYin717WcA%40mail.gmail.com.

[Maatary Okouya]

Well,

when you use mock, you might want to verify communication with the mock object. So you need to bind to a mock to do that. If you want a fake, because the original object is just to heavy for the test, then you need to change the binding to. You might well envision a class that needs to or three other service to perform its work. sometimes you wants to verify how it interact with one or all the services or you ust want to know the result when one of the service in actually used. 

Those are the case that i faced few time.

In any case, many thanks for the inputs.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/0M0LtB-1WVC7G0P5p-00ucDC%40mail.gmx.com.

[Stephan Classen]

In these kind of situations I usually create an injector specifically for this test (or group of tests) and bind only the required classes (mostly mocks and rarely an actual class).
Frameworks like juktio help a lot in cutting down the boiler plate code when creating specific injectors for tests

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAEqpkuvGh7oj-87kWeS4g%2BK15_kFUfaAJ3aPh7yxsAJPKjXfJg%40mail.gmail.com.

[Maatary Okouya]

By injector for those test you mean a module where you bind mocks right ? Actually i did something similar. I just did not like to have my production module and test module all in the same place. This is because again, i do package by feature in my test src. So i guess in my case overriding to create the same effect should be fine. Such as overriding in a fixture of a test. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/53F65361.7080607%40gmx.ch.

[Tavian Barnes]

Guice 4 has BoundFieldModule which easily lets you create a module from a test case.