TST: add broadcast_arrays() kwarg unit test for TypeError #11573
Conversation
| broadcast_arrays(x, y, dtype='float64') | ||
|
|
||
| assert ('broadcast_arrays() got an unexpected keyword' in | ||
| str(excinfo.value)) |
There was a problem hiding this comment.
Hmm, I think we are still using assert_. We should probably have a agreement about how to proceed with the new options pytest gives us.
There was a problem hiding this comment.
For reference, SciPy had this discussion a few months ago--not sure if we should similarly open an issue or ask on the mailing list? They decided in favor of allowing pytest assert usage in new PRs, but didn't mandate a mass migration.
Perhaps I'll just revert here for now?
There was a problem hiding this comment.
If we were using pytest more broadly here, I think you could spell this assert excinfo.match(r'broadcast_arrays\(\) got an unexpected keyword')
| @@ -1,6 +1,7 @@ | |||
| from __future__ import division, absolute_import, print_function | |||
|
|
|||
| import numpy as np | |||
| import pytest | |||
There was a problem hiding this comment.
We generally import system stuff first.
a27882d to
ba1fdf3
Compare
|
I've restored usage of As far as I can tell the NumPy |
|
You probably want |
|
|
|
Is the preference here for me to still call the nose-dependent test utility or can I use the pytest one to check the message raised? |
|
@tylerjereddy |
ba1fdf3 to
ff1e02f
Compare
|
@charris Thanks for pointing out my mistake; I've now completely removed the |
* broadcast_arrays() is now tested for the case when an invalid keyword argument is used; the appropriate error string content is also tested for * the TypeError message produced in the above case has been restored to the correct value in Python 3
ff1e02f to
81bd37e
Compare
|
Thanks @tylerjereddy |
In short, local coverage tests (hopefully reported online soon from: #11567) indicated that we weren't unit testing for the proper handling of invalid kwargs for
np.broadcast_arrays().In adding the unit test for this kwarg handling in this PR, I also noticed that the appropriate error message is not raised in Python 3 because
dict.keys()is not a list anymore, so the test was also adjusted to verify the correct error message & the associated source code modified to ensure an indexable object in Python 3.