Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

should we keep be._empty as 4-in-1 condition and correspondingly remove its experimental _ prefix? #544

Open
yashaka opened this issue Jul 7, 2024 · 2 comments

Comments

@yashaka
Copy link
Owner

yashaka commented Jul 7, 2024

be._empty is similar to be.blank... But be.blank works only for singular elements: if they are a value-based elements (like inputs and textarea) then it checks for empty value, if they are text-based elements then it checks for empty text content.

The be._empty condition works same but if applied to collection
then will assert that it has size 0. Additionally, when applied to "form" element,
then it will check for all form "value-like" inputs to be empty.

Hence, the blank condition is more precise, while empty is more general. Because of its generality, the empty condition can be easier to remember, but can lead to some kind of confusion when applied to both element and collection in same test. Also, its behavior can be less predictable from the user perspective when applied to form with textarea, that is both "value-like" and "text-based" element. That's why it is still marked as experimental.

@cachebag
Copy link

cachebag commented Jan 27, 2025

I briefly reviewed the test cases, and I agree that the current polymorphic behavior could create confusion

Instead of be._empty, we could make the API more explicit (although I know this approach my be more verbose, in this specific case I think that clarity > brevity):

For collections:
ss('.items').should(have.size(0))

For form/input values:
s('input').should(be.blank)
s('form').should(have.all_inputs_blank) --> a bit clearer I think?

For text content:
s('div').should(be.blank)

I do think this could make the code more predictable and self-documenting. I do hope I'm not missing any context though and my proposal makes sense.

@yashaka

@yashaka
Copy link
Owner Author

yashaka commented Jan 27, 2025

@cachebag Seems like you are right... We can keep be._empty still marked as experimental with _ prefix, just in case somebody else will find other arguments...

In meantime it seems like a good idea to add have.all_inputs_blank condition...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants