Not really, but thanks. My biggest challenge is that I have a composite Source derived from multiple Slick 3 Sources.
eg. val compositeSource = channelSource.flapMapConcat(ch => intervalSource(ch) ) For the moment I have a mockable trait with methods to construct those sources. On Tue, May 10, 2016 at 2:33 AM, Akka Team <akka.offic...@gmail.com> wrote: > Hi Richard, > > In streams, the best way to inject dependencies is to make them separate > stages/modules, where applicable. For example you can model a service that > takes requests and provides some responses as a Flow. Now you can freely > use it in tests with various test Sources/Sinks or probes. However, if you > want to be able to stub out some underlying service this Flow depends on > (maybe HTTP), you can still do it in various ways: > > - if the low level service is something like A => Future[B] then you can > just take it as a parameter when constructing the Flow > - if the low level service can be modeled as a Flow, then you can model > your high-level service as a BidiFlow. in this case you can do something > like: > > val lowLevelServiceStub: Flow[LowA, LowB] = ... //stub it > val highLevelService: BidiFlow[A, LowA, LowB, B] = ... // service under > test > val testService: Flow[A, B] = highLevelService join lowLevelServiceStub > > I am not sure this is completely what you asked for though. > > -Endre > > On Fri, May 6, 2016 at 5:51 PM, Richard Rodseth <rrods...@gmail.com> > wrote: > >> I just re-read: >> >> http://techblog.realestate.com.au/to-kill-a-mockingtest/ >> >> It's hard for me to see how to apply this thinking to a side effect like >> alsoTo() , used for monitoring in my application. >> On the input side, to make "pure" a function that creates a flow that's >> built of multiple sources (using flatMapConcat) I could imagine function >> parameters rather than a DbSources trait, and test code that provides >> different functions (rather that stubbing the trait). But I'm not sure that >> >> case class DbSources(f1: A=>Source[B, NotUsed], f2: X=>Source[Y,NotUsed]) >> >> is any better than stubable: >> >> trait DbSources { >> def f1(a:A):Source[B,NotUsed] >> def f2(x:X):Source[Y,NotUsed] >> } >> >> Anyone else wrestled with the same? >> >> On Wed, May 4, 2016 at 10:03 PM, Richard Rodseth <rrods...@gmail.com> >> wrote: >> >>> I have some streams to test. Each one implements a particular "command". >>> In recent days I have warmed up to using a combination of implicit >>> parameters and constructor injection for DI. >>> >>> >>> http://carefulescapades.blogspot.com/2012/05/using-implicit-parameters-for.html >>> >>> Some of my former singletons are now classes extending traits or >>> abstract classes. >>> >>> But I have some remaining standalone functions (in Singletons) with >>> rather long implicit parameter lists for their dependencies. eg: >>> >>> def command1(actualArgsForCommand...)(implicit ec: ExecutionContext, mat: >>> ActorMaterializer, reader: SomeReader, writer: SomeWriter, monitoring: >>> Monitoring):Future[SomeType] >>> >>> I can now mock SomeReader and SomeWriter, and use a test probe for the >>> monitor actor (a dependency of MonitoringImpl). But the method signature is >>> a bit ugly, even with the dependencies in their own parameter list. >>> >>> Is there some way to group the dependencies for a particular command in >>> a case class or something while still having them "export" implicits, or >>> would I have to redeclare within the method body? >>> implicit val reader = groupedDeps.reader >>> etc >>> >>> Or am I better off making a class per command (or related commands with >>> the same dependencies), perhaps leaving the ec, and mat in method >>> signatures, while converting the reader, writer and monitoring to class >>> constructor arguments? >>> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to akka-user+unsubscr...@googlegroups.com. >> To post to this group, send email to akka-user@googlegroups.com. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - Reactive apps on the JVM > Blog: letitcrash.com > Twitter: @akkateam > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
