-
Notifications
You must be signed in to change notification settings - Fork 186
not_to(contain) fails while not_to_contain passes #1245
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
Comments
It's arguable:) not is here negation. So in fact what you asking is negate result of check to_contain which is not the same as not_contain. This is my suspicion would need to look into code to confirm. Let me know if that's answer your question. |
To be honest I' struggling to understand the reasoning here. In comparison By the way, I found the following entry in the documentation
So this might suggest a difference you mentioned... And looking into source of member procedure not_to_contain(self in ut_expectation, a_expected sys_refcursor) is
begin
self.not_to( ut_contain(a_expected).negated() );
end; I think this is what you mentioned, yet again I do not understand why. This double negation |
The There is an extra logic when that flag is set which is probably the reason why you getting wrong results using It feels counterintuitive the way it working at the moment for this, you are correct. |
I agree that Nice catch @micdol and thanks for reporting it. Side question. Om really curious of your use case. |
I use |
See #1173 (comment) |
Describe the bug
Logically
not_to(contain)
should be the same asnot_to_contain
however the former fails while the latter passes. See reproduction steps for code.Provide version info
utPLSQL:
v3.1.14.4072-develop
Database:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.18.0.0.0
Information about client software
SQLDeveloper, SQLPlus cmd line
To Reproduce
Output:
Expected behavior
not_to_contain
should work the same way asnot_to(contain)
The text was updated successfully, but these errors were encountered: