We're starting to see a trend towards tighter integration with functional effects in testing frameworks. Weaver was really the first one here, but munit and even scalacheck now have support (via external modules). I would expect the next version of Specs will be in a similar boat.
In a sense, cats-effect-testing is a short-term "catch all" shim that fills in the gaps for frameworks which haven't already added this kind of support
I'd like to see it disappear someday :-)
Someone says "We're using ScalaTest," and they (probably) won't have much pain using cats-effect-testing with it.
I don't want people to have to use a separate testing framework to have a nice experience with
IO and Cats Effect in general
also part of my motivation here is exceptionally selfish, since you can pry Specs2 from my cold, dead hands :-P
$DAYJOB settled on sbt-docker-compose and MUnit with the cats-effect module going forward.
I was starting to feel alone.
MUnit is legitimately impressive. It's definitely missing something that I like quite a lot about specs, but I've been impressed by what I've seen from it so far.
But on personal projects I've been pretty pleased with both
then swap the traits
It does add a bit of indirection in the complexity of it all. I think as a team the decision was, at a future date we can evaluate moving new projects to a different framework if it's deemed preferably by a majority of people
val longProcess = (IO.sleep(5.seconds) *> IO(println("Ping!"))).foreverM val srv: Resource[IO, ServerBinding[IO]] = for { _ <- longProcess.background server <- server.run } yield server val application = srv.use(binding => IO(println("Bound to " + binding)) *> IO.never)What's server.run ?
@WickedUk_gitlab where's that example from? looks like http4s.
do you mean what is the type of server.run? or what are the execution semantics when it happens "after" the background?
oh the snippet is from the scaladoc https://typelevel.org/cats-effect/api/cats/effect/Concurrent.html#background[A](fa:F[A]):cats.effect.Resource[F,F[A]]
basically, it's really difficult to come up with examples that both illustrate the basic solutions (the point is to show
background, but you're using background as the non-essential thing when looking from "the outside", which is about starting some server) and not confuse people with the details (server.run isn't defined in the snippet).
what’s up?
oh well'
and likewise in projects I help maintain I file issues for questions, or encourage askers to copy their question to an issue
I think gitter being so easy is part of why scala docs are so bad - people don't ask questions in a place that's easily searched
I'm usually afraid of asking questions on github, because I don't want to clutter it with a (probably silly) questions that (probably) was already answered many times before
Don't be afraid! I'd rather reply and close tickets that have been answered previously rather than risk someone having a question that they didn't find an answer to
that too
val longProcess = (IO.sleep(5.seconds) *> IO(println("Ping!"))).foreverM val srv: Resource[IO, ServerBinding[IO]] = for { _ <- longProcess.background server <- server.run } yield server val application = srv.use(binding => IO(println("Bound to " + binding)) *> IO.never)What's server.run ?
@WickedUk_gitlab where's that example from? looks like http4s.
It's cats-effect Concurrency.background scaladoc.