Feature request: assign application/json content type for FakeRequest

[aaabramov]

Are you looking for help?

No

Play Version

2.6.5

API

Scala

Operating System

MacOS:

Darwin ***.local 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24 21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

JDK (Oracle 1.8.0_72, OpenJDK 1.8.x, Azul Zing)

java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

Library Dependencies

scalaVersion := "2.12.3"
"org.scalatestplus.play" %% "scalatestplus-play" % "3.1.1"

Feature request

I would like (even expect) that application/json content type is automatically assigned to FakeRequest when withJsonBody method is called.
I understand that there are some test cases when user tests unsupported content type but it is far rare cases. Do you agree?

This feature implementation can brake some of existing test cases described above.

Expected Behavior

1. application/json content type is automatically assigned for FakeRequest

Actual Behavior

1. Content type stays unassigned and user gets the following exception while testing scenarios with JSON:

For request 'GET /' [Expecting text/json or application/json body]

Reproducible Test Case

  val homeController = inject[HomeController]

  val request = FakeRequest()
    .withJsonBody(Json.toJson(person))
    .withHeaders(CONTENT_TYPE -> JSON)

  val response = homeController.accept.apply(request)

[richdougherty]

Sounds like something worth investigating. Since this is for testing, we would still need to be able to send the body without the Content-Type header, e.g. so users can test failure conditions in their application.

[aaabramov]

Hi @richdougherty,

For these purposes users can use withBody method or explicitly set no headers like

FakeRequest()
    .withJsonBody()
    .withHeaders()

Testing with no content type headers is much more rare scenario than testing controllers at all.
What do you think?

[richdougherty]

I'm open to the idea. Would you like to sketch out the API changes? One thing to consider is that existing methods should continue to behave the same way—existing tests should preserve their behaviour. Another thing to think about is how this looks in equivalent the Java API.

[aaabramov]

Yes, I will try to make initial drop in few days. And I think we can than move this discussion closer to code - PR.

[sankarpa]

Hey @Abrasha, @richdougherty
Anybody working on this issue? If not I can take this up.

[aaabramov]

Picking this up

[aaabramov]

I have made an initial drop for this.
Checking for backward compatibility.

The only thing we can brake are tests that are checking for 415 Unsupported Media Type.
Any ideas how to properly migrate? Or should we mention this in docs?