Hi Stephan, *"My recomendation is to use constructor injection. And then in the unit test I simply call the constructor. This way I have full controll over what is passed to the subject under test."*
Yes, thank you for the suggestion. By not using dependency injection during unit test, I find the test to be easier to understand (at least in my simple case) because what's being passed in to the SUT is explicitly written. On Tue, May 3, 2016 at 10:39 PM Russ Milliken <[email protected]> wrote: > +1 > Using constructor injection and not using DI in unit tests is the way to > go, for exactly the reasons that Stephan describes. > > On Tue, May 3, 2016 at 12:30 AM, Stephan Classen <[email protected]> > wrote: > >> If this is about testing: >> My recomendation is to use constructor injection. And then in the unit >> test I simply call the constructor. This way I have full controll over what >> is passed to the subject under test. >> As a consequence of this. I do not make use of dependency injection >> during unit testing. Which then removes the need to bind different objects >> for production and testing. >> >> Integration testing is different but there it is most of the time >> sufficient to change bindings to a few external resources such as DB, mail, >> etc. >> >> >> Am 3. Mai 2016 02:45:47 MESZ, schrieb Andree Surya < >> [email protected]>: >>> >>> Thanks for the responses. >>> >>> *"Look at guice-persist or onami-persist. They deal wir DB connections >>> which also need to be closed after it has been used. To do so they both use >>> the concept of UnitOfWork. The application is then responsible for spanning >>> the UnitOfWork around the code which needs the resource."* >>> >>> Thanks for the reference. *UnitOfWork* is a new concept to me and I'll >>> take some time to read on it. >>> >>> *"But in general I'd say binding something like a Reader is >>> questionable. I'd rather bind something stateless like a Path, which can be >>> used to open a Reader by whoever needs to."* >>> >>> My original intention was to make it easy replace a FileReader with a >>> StringReader during unit test, thus avoiding dependency to the file system. >>> I agree, though, that injecting a stateful object like a Reader could >>> possibly create confusion concerning state management. The Parser depends >>> on the Reader, but because the Reader is injected from outside, somebody >>> else could have messed it up (closing, moving the cursor, etc). >>> >>> *"bind something that can give you the resource rather than the resource >>> itself (unless the lifetime is super well defined, like >>> servletoutputstream). For example, guava ByteSource/CharSource would work >>> great."* >>> >>> Thank you, I think I'll proceed this approach. This way, I can can >>> easily replace file-based input source to an in-memory data during unit >>> test, while encapsulating the responsibility of opening/closing the stream >>> within the Parser object. >>> >>> Andree >>> >>> On Tue, May 3, 2016 at 3:44 AM Luke Sandberg <[email protected]> >>> wrote: >>> >>>> +1 to that. >>>> >>>> bind something that can give you the resource rather than the resource >>>> itself (unless the lifetime is super well defined, like >>>> servletoutputstream). For example, guava ByteSource/CharSource would work >>>> great >>>> >>>> On Mon, May 2, 2016 at 8:47 AM Tavian Barnes <[email protected]> >>>> wrote: >>>> >>>>> On Friday, 29 April 2016 19:40:44 UTC-4, Andree Surya wrote: >>>>>> >>>>>> Is it a commonplace to inject a resource that should be cleaned-up after >>>>>> (e.g. Closable)? In general, who has the responsibility for the clean-up? >>>>>> >>>>>> >>>>> If the Reader is unscoped, then everybody who injects it gets a >>>>> different instance, so it's up to the class that injects it to close it. >>>>> >>>>> But in general I'd say binding something like a Reader is >>>>> questionable. I'd rather bind something stateless like a Path, which can >>>>> be used to open a Reader by whoever needs to. >>>>> >>>>> -- >>>>> >>>> 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 https://groups.google.com/group/google-guice. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/google-guice/f293df1e-0653-4bcf-9841-e1c5dc281838%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/google-guice/f293df1e-0653-4bcf-9841-e1c5dc281838%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> 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/rcUWE--TfRQ/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 https://groups.google.com/group/google-guice. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/google-guice/CAO9V1MKVE96AxX6vYftRA92o7ObQn-K%2BO1jDbf4%2B-PeStmqu_g%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/google-guice/CAO9V1MKVE96AxX6vYftRA92o7ObQn-K%2BO1jDbf4%2B-PeStmqu_g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> 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 https://groups.google.com/group/google-guice. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-guice/B9FE2737-CB62-45D7-A006-71BD8E0EC548%40gmx.ch >> <https://groups.google.com/d/msgid/google-guice/B9FE2737-CB62-45D7-A006-71BD8E0EC548%40gmx.ch?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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/rcUWE--TfRQ/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 https://groups.google.com/group/google-guice. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-guice/CANEiXrpBz84KyBXn91qm_TFdtoBYvfPMsFgEOwa1-q0mPigCGw%40mail.gmail.com > <https://groups.google.com/d/msgid/google-guice/CANEiXrpBz84KyBXn91qm_TFdtoBYvfPMsFgEOwa1-q0mPigCGw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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 https://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAFVK2JSbfGhwA3qAn-ZWr2YSXdyg9fQc649y0vy%2Bgk126N1RaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
