Refactor Http4sMatchers to be generic on F-Type #2080
Conversation
As described in issue #1430, the Http4sMatchers trait was not parametrised on the Effect type. Neither was the parent trait IOMatchers. To fix the situation, this commit does the following: - We factor out the trait IOMatchers into a RunTimedMatchers trait, which keeps most fo the IOMatchers trait methods and logic, but is generic on the effect type `F[_]`. Since IOMatchers was using some specific methods of cats.effect.IO, we need to extract those (template method pattern). Note that this method do not correspond to any current type-class. - We turn IOMatchers into an extension of RunTimedMatchers that specialises those abstract methods, to the methods of IO , - We make `Http4sMatchers` generic on the F type. Luckily, this is just replacing "IO" with F - We add an `Http4sMatchersIO`, which unifies those traits. This will help for an easy migration for those previously using `Http4sMatchers`.
you can |
|
specs2 has recently gained support for Getting from here to there is complicated: specs2 now depends on scalacheck-1.14, but our laws dependencies are only published for scalacheck-1.13. I think this strategy is the right place to put things in the long term, but severely complicates getting this merged and released. Thoughts? |
I'd also like to have an http4s-laws (no specs2 dependency) and an http4s-specs2 module for the matchers. Maybe that split could be coordinated with a scalacheck-1.14 upgrade and give us an excuse to adopt a specs2-owned trait, and we adopt these as a temporary fix. |
I agree that As for the |
I think the problem with |
@rossabaker I have opened a PR in Looking through the build files of those projects, I have found a curious thing: In any case, I humbly believe that upgrading test dependencies, and watching for any regression that may introduce, goes beyond the scope of the original issue. |
LGTM. We're going to have a mess when Scala 2.13 forces us to straddle the scalacheck-1.13 vs. 1.14 divide. Hopefully we can get cats-laws and cats-effect-laws crossbuilt for 1.14 by that point. But we'll cross that bridge when we come to it: this is strictly an improvement where we're at today. |
Resolves #1430.
As described in issue #1430, the
Http4sMatchers
trait is not generic on the effectF[_]
type, and neither was a parent traitIOMatchers
trait. We try to address this situation doing the following:IOMatchers
into aRunTimedMatchers
trait, which keeps most fo the IOMatchers trait methods and logic, but is generic on the effect typeF[_]
. Since IOMatchers was using some specific methods ofcats.effect.IO
, we need to extract those as abstract method, following the GoD template-method pattern.IOMatchers
into an extension ofRunTimedMatchers
that specialises those abstract methods, to the methods of IO.Http4sMatchers
generic on the F type. Luckily, this is just replacing "IO" with FOther issues and related or future work.
One thing to note is that, in the
RunTimedMatchers
, we need to declareF
-generic abstractions for two methods in theIO
class:unsafeRunSync
, which takes anIO[A]
and returns anA
(or throws an exception); andunsafeRunTimed
, which takes anIO[A]
and a timeout, and either returns anA
in time or throws a timeout error.These methods have no type-class capturing them, although an issue was opened in
cats-effect
that proposed creating a type-class that would have included the first method: typelevel/cats-effect#230It should be noted that, since the existing design is a lattice of inheritance and mixins, the solution only adds two more nodes to that lattice. While it may be possible to replace the design by one with less inheritance, which would avoid the inner (path-dependent) class
TimedMatcher
, that would exceed the scope of the original ticket IMHO.