Asserting "non empty"

[DannyBen]

First, may I suggest opening the "Discussions" tab so people have a place to ask the community questions without polluting the issues?

---

I am trying to figure out the simplest way to assert non empty captures. Could not find anything in the docs.

First, I expected this to already fail if it is empty:

[Captures]
auth_token: xpath "string(//input[@name='no-such-input']/@value)"

but I understand if the design intention was to allow capturing empty things. So then, I was happy to find the exist matcher:

GET http://example.com
HTTP/1.1 200

[Captures]
auth_token: xpath "string(//input[@name='no-such-input']/@value)"

[Asserts]
# Expected this to fail, but it passes
variable "auth_token" exists

# Is this the only way to assert "non empty"?
# variable "auth_token" matches /^.{60,100}$/

now I am confused - what is the purpose of exists then? Does it just test that I used it as a variable name in the captures section above?

So the only way to test that the captured variable is non empty I found was using some regex:

[Asserts]
variable "auth_token" matches /^.{60,100}$/

If this is the only way, I would like to suggest a matcher nonempty or to change the exists behavior (although I am sure it has its own purpose).

[fabricereix]

Hi @DannyBen,
We tried the Discussions tab before, but we found it often redundant with issues. The distinction between them was not always clear.

The exists predicate for example can be used to test whether an header or a cookie is present or not
header "X-Powered-By" exists
This is clearly different from an empty value.

We could add the empty predicate which is exactly what you need. It is now very common is programming language.
variable "auth_token" not empty

[fabricereix]

The empty predicate could be used for both strings and collection.

[DannyBen]

We tried the Discussions tab before

Alright, cool - so I take it that opening such "question" issues is acceptable?

We could add the empty predicate which is exactly what you need

Excellent, this would be nice.
In my case, I spent some 20 minutes not understanding why my script fails, only to learn that my captured authenticity token had a typo, and was received empty.

[jcamiel]

Just a side note, about the behaviour of xpath capture. We're doing the same thing that a browser will do.
For instance, you can open a Javascript console in Firefox/Chrome and test it:

>> $x("//input[@name='no-such-input']/@value") 
Array []

The path expression //input[@name='no-such-input']/@value returns an empty collection.
With the string function:

>> $x("string(//input[@name='no-such-input']/@value)")
""

That's why your capture returns an empty string.
In your case, as xpath expressions return collections (when not using xpath functions such as count, string, normalize-space etc...) you can test the collection size to see if it is empty or not:

GET http://example.com

HTTP/1.1 200
[Asserts]
xpath "string(//input[@name='no-such-input']/@value)" count == 0
[Captures]
auth_token: xpath "string(//input[@name='no-such-input']/@value)"

That's said, in this case, your solution might be better (it avoids the repetition of the path expression)

[DannyBen]

Thanks for clarifying. Yes I prefer the "semantic" and DRY approach. Once the empty predicate will be available, I will update.