| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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
| Back | FazBrowse Home | New Git URL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityI have encountered this issue, and thanks for the PR! Would this simple test below work? @sveneschlbeck @tacaswell
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality@yuanx749 Thanks for the input...
@tacaswell Is that still the same logic? I think this is not exactly the same/equivalent message, right?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityPicking the conditions on the test is a bit of an art.
Too specific and you can end up with a really brittle test suite that breaks on tiny changes that no user will ever care about. A test suite that is always broken or you are always having to change with the code is not really doing its job and causing you a whole lot of work!
Too general it will always pass, even if you make changes that significantly break users. This is also not great as again you test suite is not doing its job and still causing you a whole bunch of work.
As written the tests are failing because https://github.com/matplotlib/matplotlib/runs/4566462001?check_suite_focus=true#step:12:142
________________________ TestScatter.test_scatter_color ________________________ 143 [gw1] linux -- Python 3.10.1 /opt/hostedtoolcache/Python/3.10.1/x64/bin/python self = <matplotlib.tests.test_axes.TestScatter object at 0x7f345c9acbb0> def test_scatter_color(self): # Try to catch cases where 'c' kwarg should have been used. with pytest.raises(ValueError): plt.scatter([1, 2], [1, 2], color=[0.1, 0.2]) with pytest.raises(ValueError): plt.scatter([1, 2, 3], [1, 2, 3], color=[1, 2, 3]) > with pytest.raises(ValueError, match=f"{c!r}"): E NameError: name 'c' is not defined lib/matplotlib/tests/test_axes.py:2215: NameErrorin the namespace where the fstring is being evaluated we do not have c defined. You could change the test so the you do
which tests that the literal string 'blue\\n' shows up. With @yuanx749 's suggestion you do not have to change anything else and it checks that at least one of new line, tab, or carriage return is literally in the message.
Between these two I would lean slightly towards searching for 'blue\n' (assume the escaping is right), in case we in the future add a note like "be careful you do not have a trailing \t or \n!" into the error message. In that case we would be able to stop putting the repr in and still have the test pass. However, I would be happy to merge this in either case so long as the tests pass now, the new test would fail without your other changes, and you can make a case as to why you wrote the test the way you did if asked.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.