This raised a value error before, so maybe test the error message with a matches=... to the pytest.raises?

Isn't this just to test whether an error gets raised when given the blue\n argument? I know that the error was thrown before but in addition to changing the error message slightly, we wanted to add a test.
Maybe, I am not understanding you correctly...

I think we also want to test that the repr is being used, not the str...

Okay, now I got what you mean. I changed it but I now realise that this is misplaced here. It now reads

with pytest.raises(ValueError, match=f"'c' argument must be a color, "
                           f"a sequence of colors, or a sequence of numbers, "
                           f"not {c!r}"):
            plt.scatter([1, 2], [1, 2], color='blue\n')

But the entire section is about examples, where color was used and c should have been used. However, this is not the case here. This case is about c already being used but the error message being too unspecific. The example should read instead

with pytest.raises(ValueError, match=f"'c' argument must be a color, "
                           f"a sequence of colors, or a sequence of numbers, "
                           f"not {c!r}"):
            plt.scatter([1, 2], [1, 2], c='blue\n')

but be placed in a different section, maybe underneath a comment like this:

# Check for the specificity of error message if invalid 'c' argument is given

Since I don't know if such a section already exists and - if not - where to place it, I wanted to wait for your opinion.

I would go with a slightly simpler test and only search for a literal new line (''\n'") rather than trying to match the whole thing.

The input here is also a regular expression which can require escaping a lot of symbols which can get tedious. I am also not sure we want to pin down in a test the exact wording just that we got back the reper of the string you put in.

Okay, I understand. Nevertheless, the question where to put it remains. Should I just append the example to the previous ones separated by a comment?

It is not super important either way. The benefit of putting it in an existing test is we have fewer tests and the test suite runs marginally faster, the benefit of putting it in its own test is if it fails it is much more obvious what part of the test is failing!

I have encountered this issue, and thanks for the PR! Would this simple test below work? @sveneschlbeck @tacaswell

@yuanx749 Thanks for the input...
@tacaswell Is that still the same logic? I think this is not exactly the same/equivalent message, right?

Picking 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: NameError

in the namespace where the fstring is being evaluated we do not have c defined. You could change the test so the you do

c = 'blue\n'
with pytest.raises(ValueError, match=f"{c!r}"):
    plt.scatter([1, 2], [1, 2], c=c)

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.