Reputation: 1681
Context :
Jakarta validation annotations seem straightforward at first glance but it's hard to understand the fine prints. The documentation has no examples and some people (including me) struggle with the corner cases, as shown by those stackOverflow questions:
It gets worse when used within RestEasy. Consider the following endpoint:
@GET
@Path("expectsLong")
@Produces(MediaType.TEXT_PLAIN)
public Response expectsLong(
@NotNull @PositiveOrZero @QueryParam("searchValue") final Long searchValue)
{
return ok(searchValue);
}
At first glance it looks air-tight.
For example GET /expectsLong?searchValue=-1
returns a nice HTTP 400 with a clear message
[PARAMETER]
[expectsLong.searchValue]
[must be greater than or equal to 0]
[-1]
The problem:
There's all sorts of annoying caveats that you won't know exist unless you try :
GET /expectsLong?searchValue=not_a_number
RestEasy does raise an exception but it's not caught and ends up as HTTP 500 or HTTP 404 depending on how you blundered. It's by design but it's very awkward.
My attempt:
I've decided to explore the scenarios manually, but it's impossible long because every change in the annotations calls for a rebuild, a redeploy, and if I'm unlucky even a server restart. That's not sustainable.
The question :
Is there a way of instantiating the overall RestEasy context (of even just one endpoint) in order to QUICKLY test exactly what HTTP status it will return, and with what payload?
Alternatively, is there some playground online? Any other out-of-the-box-thinking solution that you personally use on a regular basis?
More generally, is there a way of testing those behaviours in some unit tests? I wouldn't know how to instantiate the bare minimum skeleton to have both RestEasy and a fake annotated endpoint.
Upvotes: 0
Views: 40