Those are good reasons. There's a third one, readability. Like you say, re-use is good, and if done right you can argue it's readable. However, in a test you need to know EXACTLY what the test is doing right there and then. You don't want to have to go visit a constant to see what's being tested. Kent beck did a nice series on Test Desiderata awhile back, and one of the points was not abstracting tests.
Obviously abstracting the actual test code can be reasonable if it's highly re-used; it's a trade off on readability vs re-use. This is typically the case with end to end tests. "Login" functionality needs abstraction so that you don't repeate yourself over and over, and if "how" a Login changes you change it in one place. But that "Login" abstraction itself is test code, not production code.
Abstraction in tests can also be useful in some cases because you have to do common setup stuff that isn't really the centre of the test. Again this happens in component tests, e2e tests, but usually not unit tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Those are good reasons. There's a third one, readability. Like you say, re-use is good, and if done right you can argue it's readable. However, in a test you need to know EXACTLY what the test is doing right there and then. You don't want to have to go visit a constant to see what's being tested. Kent beck did a nice series on Test Desiderata awhile back, and one of the points was not abstracting tests.
Obviously abstracting the actual test code can be reasonable if it's highly re-used; it's a trade off on readability vs re-use. This is typically the case with end to end tests. "Login" functionality needs abstraction so that you don't repeate yourself over and over, and if "how" a Login changes you change it in one place. But that "Login" abstraction itself is test code, not production code.
Abstraction in tests can also be useful in some cases because you have to do common setup stuff that isn't really the centre of the test. Again this happens in component tests, e2e tests, but usually not unit tests.