Return to Answer

First, it is never a good idea to distribute knowledge about the correct value for something like NAME_LENGTH_LIMIT over too many places in the code. Ideally, there should be a single source of truth. Imagine you have 20 tests which all depend on this value, do you really want to change them all when when the requirement for the maximum name length will be changed?

Of course, imagine there are two persons involved, one writing the tests and another one writing the production code. Now the test author wants to verify the production code author used the correct value, without looking into their code. Then - hypothetically - introducing a constant like NAME_LENGTH_LIMIT_REQUIRED=50 into the tests (or some of them) could be an option. That can keep the test code DRY and allows to distinguish beetween tests for the behaviour (using NAME_LENGTH_LIMIT) and test for the actual number (using NAME_LENGTH_LIMIT_REQUIRED).

In reality, however, I think it is often much more effective to verify the correctness of NAME_LENGTH_LIMIT by a code review, and stay with the solution of using just one constant. That approach will suit you most in case the test code author and the prod code author are the same person.

First, it is never a good idea to distribute knowledge about the correct value for something like NAME_LENGTH_LIMIT over too many places in the code. Ideally, there should be a single source of truth. Imagine you have 20 tests which all depend on this value, do you really want to change them all when when the requirement for the maximum name length will be changed?

Of course, imagine there are two persons involved, one writing the tests and another one writing the production code. Now the test author wants to verify the production code author used the correct value, without looking into their code. Then - hypothetically - introducing a constant like NAME_LENGTH_LIMIT_REQUIRED=50 into the tests (or some of them) could be an option. That can keep the test code DRY and allows to distinguish beetween tests for the behaviour (using NAME_LENGTH_LIMIT) and tests for the actual number (using NAME_LENGTH_LIMIT_REQUIRED). As mentioned by @BartVanIngenSchenau, you will probably end uo with a single test

 assert(NAME_LENGTH_LIMIT == NAME_LENGTH_LIMIT_REQUIRED)

and if that is the only place where NAME_LENGTH_LIMIT_REQUIRED is used, replacing the constant by the literal, like assert(NAME_LENGTH_LIMIT == 50) is completely sufficient.

In reality, however, I think it is often much more effective to verify the correctness of NAME_LENGTH_LIMIT by a code review. That approach will suit you most in case the test code author and the prod code author are the same person.

First, it is never a good idea to distribute knowledge about the correct value for something like NAME_LENGTH_LIMIT in too many places in the code. Ideally, there should be a single source of truth. Imagine you have 20 tests which all depend on this value, do you really want to change them all when when the requirement for the maximum name length will be changed?

Of course, imagine there are two persons involved, one writing the tests and another one writing the production code. Now the test author wants to verify the production code author used the correct value, without looking into their code. Then - hypothetically - introducing a constant like NAME_LENGTH_LIMIT_REQUIRED=50 into the tests (or some of them) could be an option. That can keep the test code DRY and allows to distinguish beetween tests for the behaviour (using NAME_LENGTH_LIMIT) and test for the actual number (using NAME_LENGTH_LIMIT_REQUIRED).

In reality, however, I think it is often much more effective to verify the correctness of NAME_LENGTH_LIMIT by a code review, and stay with the solution of using just one constant. That approach will suit you most in case the test code author and the prod code author are the same person.

First, it is never a good idea to distribute knowledge about the correct value for something like NAME_LENGTH_LIMIT over too many places in the code. Ideally, there should be a single source of truth. Imagine you have 20 tests which all depend on this value, do you really want to change them all when when the requirement for the maximum name length will be changed?

Of course, imagine there are two persons involved, one writing the tests and another one writing the production code. Now the test author wants to verify the production code author used the correct value, without looking into their code. Then - hypothetically - introducing a constant like NAME_LENGTH_LIMIT_REQUIRED=50 into the tests (or some of them) could be an option. That can keep the test code DRY and allows to distinguish beetween tests for the behaviour (using NAME_LENGTH_LIMIT) and test for the actual number (using NAME_LENGTH_LIMIT_REQUIRED).

In reality, however, I think it is often much more effective to verify the correctness of NAME_LENGTH_LIMIT by a code review, and stay with the solution of using just one constant. That approach will suit you most in case the test code author and the prod code author are the same person.

First, it is never a good idea to distribute knowledge about the correct value for something like NAME_LENGTH_LIMIT in too many places in the code. Ideally, there should be a single source of truth. Imagine you have 20 tests which all depend on this value, do you really want to change them all when when the requirement for the maximum name length will be changed?

Of course, imagine there are two persons involved, one writing the tests and another one writing the production code. Now the test author wants to verify the production code author used the correct value, without looking into the code. Then - hypothetically - introducing a constant like NAME_LENGTH_LIMIT_REQUIRED=50 into the tests (or some of them) could be an option. That can keep the test code DRY and allows to distinguish beetween tests for the behaviour (using NAME_LENGTH_LIMIT) and test for the actual number (using NAME_LENGTH_LIMIT_REQUIRED).

In reality, however, I think it is often much more effective to verify the correctness of NAME_LENGTH_LIMIT by a code review, and stay with the solution of using just one constant. But YMMV.

First, it is never a good idea to distribute knowledge about the correct value for something like NAME_LENGTH_LIMIT in too many places in the code. Ideally, there should be a single source of truth. Imagine you have 20 tests which all depend on this value, do you really want to change them all when when the requirement for the maximum name length will be changed?

Of course, imagine there are two persons involved, one writing the tests and another one writing the production code. Now the test author wants to verify the production code author used the correct value, without looking into their code. Then - hypothetically - introducing a constant like NAME_LENGTH_LIMIT_REQUIRED=50 into the tests (or some of them) could be an option. That can keep the test code DRY and allows to distinguish beetween tests for the behaviour (using NAME_LENGTH_LIMIT) and test for the actual number (using NAME_LENGTH_LIMIT_REQUIRED).

In reality, however, I think it is often much more effective to verify the correctness of NAME_LENGTH_LIMIT by a code review, and stay with the solution of using just one constant. That approach will suit you most in case the test code author and the prod code author are the same person.