+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 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/CANEiXrpBz84KyBXn91qm_TFdtoBYvfPMsFgEOwa1-q0mPigCGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
