How can I use scalamock to stub WSRequestHolder.post() in Play

Question

I'm having trouble using scalamock to stub the post() method in WSRequestHolder in the Play WS library.

Here's what I'm trying:

(request.post[Results.EmptyContent](_ : Results.EmptyContent)(_ : Writeable[Results.EmptyContent], _: ContentTypeOf[Results.EmptyContent])) when(Results.EmptyContent(), *,*) returns Future.successful(response)

The aim is to return Future.successful(response) when a post() is called with Results.EmptyContent.

The compiler error I'm getting is:

value when is not a member of (play.api.mvc.Results.EmptyContent, play.api.http.Writeable[play.api.mvc.Results.EmptyContent], play.api.http.ContentTypeOf[play.api.mvc.Results.EmptyContent]) => scala.concurrent.Future[play.api.libs.ws.WSResponse] (request.post[Results.EmptyContent](_ : Results.EmptyContent)(_ : Writeable[Results.EmptyContent], _: ContentTypeOf[Results.EmptyContent])).when(Results.EmptyContent(), ,) returns Future.successful(response)

Any idea what I'm doing wrong?

---

UPDATE

There is something going on here that I don't really understand. If I define the following trait:

  trait TestTrait {
    def post[T](data: T)(implicit wrt: Writeable[T], ct: ContentTypeOf[T]): Future[WSResponse]
  }

which has a post() method with the same signature as WSRequestHolder.post(), I can successfully stub it. So, there is some weirdness specific to WSRequestHolder.post() that is manifesting in this problem. Some nuance with regard to type inference maybe?

---

UPDATE 2

So, I've found a workaround. In my test, I define a new trait that extends WSRequestHolder:

trait StubbableWSRequestHolder extends WSRequestHolder {
  override def post[T](data: T)(implicit wrt: Writeable[T], ct: ContentTypeOf[T]): Future[WSResponse] =
    withMethod("POST").withBody(body).execute()
}

In my test, I create my stub from this trait. As you can see, unlike in WSRequestHolder, my overriden signature for post() is explicit about the return type of Future[WSResponse].

The question remains, though, as to what exactly is going on here? Is this some kind of limitation with scalamock with regard to type inference?

Answer 1

This issue was fixed in the ScalaMock-3.2.1