Confused about behavior of >, >=, <, <= versus ==, !=

[danielbprice]

Let's say I have an API which returns a list of objects, and they are supposed to be sorted in order by their createdAt field in ascending order. Let us assume that createdAt is a timestamp string such as 2022-08-06T05:55:35Z.

So I would like to do this:

  GET {{url}}/api/widgets

  HTTP/* 200
  [Captures]
  zero_created: jsonpath "$[0].['createdAt']"
  [Asserts]
  jsonpath "$[1].['createdAt']" > {{zero_created}}

This results in:

error: Parsing predicate value
 34 | jsonpath "$[1].['createdAt']" > {{zero_created}}
    |                                 ^ invalid predicate value

However hurl will let me write an assertion using ==, like this:

  jsonpath "$[1].['createdAt']" == {{zero_created}}

(Of course, this assertion will fail unless the timestamps are the same, but the point is that it isn't illegal). Is the problem here that the <, <=, etc. comparisons are simply not implemented for string values? For what it's worth it also seems like it doesn't work when the value is clearly numeric, like this:

  GET {{url}}/api/all-widgets

  HTTP/* 200
  [Captures]
  all_widget_count: jsonpath "$" count
  [Asserts]
  jsonpath "$" count == {{all_widget_count}}   # <--- is fine
  jsonpath "$" count <= {{all_widget_count}}   # <--- is not fine, error: Parsing predicate value

Thanks!

[fabricereix]

Hello,
Yes, the comparison predicate (<, <=, >, >=) are not supported for String, only for numbers values (Int and Float).
But it could also make sense to support String as well.

I could reproduce your bug with the count example.
The bug is not with the numeric value as such, but with the variables.

We can leave this issue as an enhancement for supporting String.
I've created another one #799 for tha variable bug.
Thanks a lot for spotting it

[jcamiel]

Hi @danielbprice we've implemented the comparison on strings values. You can pull master to test it. Happy to have your feedback, and thanks for your suggestions!