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.
Am 21.08.2014 16:58 schrieb Maatary Okouya <[email protected]>:
-- 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 scopeIn any case, why are you against using the module override functionality ? What is wrong with it?--On Thu, Aug 21, 2014 at 4:31 PM, Thomas Broyer <[email protected]> wrote:
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.+1Wrt 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 ;-) )--To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/762ada39-ba7f-4eb7-8b36-6fac5104b46a%40googlegroups.com.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
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 [email protected].
To post to this group, send email to [email protected].
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.
For more options, visit https://groups.google.com/d/optout.
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 [email protected].
To post to this group, send email to [email protected].
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/0M0LtB-1WVC7G0P5p-00ucDC%40mail.gmx.com.
For more options, visit https://groups.google.com/d/optout.
