-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
UnitTests using assertTrue(x, y) instead of assertEqual(x, y) #7634
Labels
Comments
good catch, yeah we should probably excise all of those from tests to use assert equal .. note since we're using pytest we could also just assert x == y albeit we mostly do that in non unittest case derived tests. |
there's quite a few of these
|
This was referenced Oct 20, 2022
Thanks for the report - closed via #7914 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Some unit tests, such as those in test_apigw.py, use assertions like these:
self.assertTrue(len(resources), 1)
These will resolve even when len(resources) is greater than one.
Instead, either of the following should be used:
self.assertTrue(len(resources) == 1)
self.assertEqual(len(resources), 1)
Arguably the second form is better as it will show more meaningful error information when the test fails.
There should be some check to prevent using assertTrue with multiple arguments in the codebase to avoid this error in future.
This happens because the function signature of assertTrue accepts 2 arguments:
assertTrue(self, expr, msg=None)
In other words, the following assertion will pass:
self.assertTrue(1==1, 3)
And the one below will fail with the message "3"
self.assertTrue(1==2, 3)
What did you expect to happen?
Assertion should fail when 2 != 1 but it doesn't
Cloud Provider
Amazon Web Services (AWS)
Cloud Custodian version and dependency information
Policy
No response
Relevant log/traceback output
No response
Extra information or context
No response
The text was updated successfully, but these errors were encountered: