Testing null/empty path parameters

4,264 views
Skip to first unread message

Benjamin Sproule

unread,
Dec 23, 2015, 10:05:38 AM12/23/15
to REST assured
So I'm using rest-assured to test our APIs, but we are getting a 500 response code in production when a path parameter is null/empty. As part of a fix, I would like to have regression tests, as we test other scenarios, just not empty path parameters. Is there a way to do this without getting `java.lang.IllegalArgumentException: Path parameters were not correctly defined. Undefined path parameters are: paramName`?

The test is using similar code to below:

given() 
    .basePath("entity") 
    .pathParam(CLIENT_ID, "") 
    .pathParam(SECTION, "section") 
    .pathParam(UUID_TYPE, "uuidType") 
    .pathParam(UUID, "uuid") 
    .get("/{clientId}/{section}/{uuidType}/{uuid}") 
    .then() 
    .assertThat() 
    .statusCode(is(400));

Johan Haleby

unread,
Dec 23, 2015, 10:07:49 AM12/23/15
to rest-a...@googlegroups.com
Are you using REST Assured 2.8.0?

--
You received this message because you are subscribed to the Google Groups "REST assured" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rest-assured...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Benjamin Sproule

unread,
Dec 23, 2015, 10:29:04 AM12/23/15
to REST assured
Originally I was using 2.4.0, but I've just upgraded to 2.8.0 and getting the same error. If I put the values into the complete string URL (e.g. `.get("entity//section/uuidType/uuid)`) then it works fine.

Johan Haleby

unread,
Dec 23, 2015, 10:41:46 AM12/23/15
to rest-a...@googlegroups.com
Alright then I suspect that it's by design :). Not sure whether or not it's a good idea to actually support empty path parameters. I suspect that in MOST cases you don't want to supply an empty path param?

Benjamin Sproule

unread,
Dec 23, 2015, 11:51:45 AM12/23/15
to REST assured
In most cases you don't want to allow it, however, it is still a possibility.

Looks like RequestSpecificationImpl#findNamedPathParamValue line 1688 is calling trimToNull, so that returns null. So it looks like this is by design, but I don't know why you would want to disable a fully testable scenario.

Johan Haleby

unread,
Dec 23, 2015, 12:09:26 PM12/23/15
to rest-a...@googlegroups.com
I didn't think about it, that's the honest answer. I'm still not 100%  convinced that we should allow it though.. Are you certain it would be a good idea if you try to look at it objectively?

Benjamin Sproule

unread,
Dec 23, 2015, 3:33:19 PM12/23/15
to REST assured
My current predicament is that we are returning a 500 for missing parameters, a bug as not providing a path parameter is not an internal server error, but a bad request. Now whilst I can fix the issue at hand, I cannot test is via rest-assured. The current behaviour of rest-assured, would be the same as junit not allowing you to pass in a null parameter. Yes, I could fix it without automated tests, but that's a waste of future developer/QA time. Surely it's the job of a testing framework to allow you to test all eventualities? Also, manipulating the values that I pass in, re the trimToNull is surely not the job of a testing framework?

Johan Haleby

unread,
Dec 24, 2015, 1:36:57 AM12/24/15
to rest-a...@googlegroups.com
But in your case I suppose you have a workaround? Simply don't define a placeholder for the empty value. For example if "section" is empty you could do:

given() 
    .basePath("entity") 
    .pathParam(CLIENT_ID, "") 
    .pathParam(UUID_TYPE, "uuidType") 
    .pathParam(UUID, "uuid") 
    .get("/{clientId}//{uuidType}/{uuid}") 
    .then() 
    .assertThat() 
    .statusCode(is(400));

Or does this not work?

Regards,
/Johan
 

Benjamin Sproule

unread,
Dec 24, 2015, 4:21:47 AM12/24/15
to REST assured
True, that does make sense. Just we actually have a larger set of path parameters, so duplicating that string is going to be a pain, but I see where you are coming from. I still think it makes sense to accurately replace the placeholder with the provided value, as it's up to me to decide what I am testing, not the framework. The point of using the .pathParam is to make it easier to read and be able to re-use the URL string. I guess it's a question of flexibility and maintenance of the tests over what the framework wants to be allowed to do.

Johan Haleby

unread,
Jan 4, 2016, 1:02:44 AM1/4/16
to rest-a...@googlegroups.com
Sorry for the late response, I've been away on vacation. 

I agree with you, since RA is a test framework you might want to test what happens if a path parameter is empty. Then I don't suppose we should even trim the path parameters automatically, this ought to be up to the user. Do you agree? Could you please add this as an issue?

Benjamin Sproule

unread,
Jan 15, 2016, 11:27:03 AM1/15/16
to REST assured
My turn to apologise for the late response. I've also been on holiday.

I agree, I think it makes sense for the user to decide on that behaviour. Here is the issue on GitHub https://github.com/jayway/rest-assured/issues/631.

Johan Haleby

unread,
Jan 15, 2016, 12:31:15 PM1/15/16
to rest-a...@googlegroups.com
Thanks.

80Vikram

unread,
Nov 23, 2017, 10:01:17 AM11/23/17
to REST assured
Hi Benjamin,

can you please clarify how to pass null value to a parameter ?

I need to check end point with 3 parameters by passing one of the parameter value as null.

- When I directly put null in url string it's failing

Thanks,
Vikram

80Vikram

unread,
Nov 23, 2017, 10:36:30 AM11/23/17
to REST assured
I tried below 2 options but none of them is working

given().
contentType("application/json").
pathParam("NI", 3000).
pathParam("DP", "null").
when().
get("http://end_point?netIncome={NI}&downPayment={DP}&loanDuration=12").
then().
statusCode(200);


Throws 400


given().
contentType("application/json").
pathParam("NI", 3000).
pathParam("DP", null).
when().
get("http://
end_point?netIncome={NI}&downPayment={DP}&loanDuration=12").
then().
statusCode(200);

java.lang.IllegalArgumentException: parameterValue cannot be null


Is this bug ? or am I doing something wrong here ?

Thanks,
Vikram


Reply all
Reply to author
Forward
0 new messages