Meaning that unit tests should be independent of one another, self-contained, and not entangled with other tests, or global state, or unit test order dependent (i.e., the finishing state of one unit test is presupposed as the starting state of a different unit test, so they are implicitly conjoined).
Some unit test frameworks provide a convenient setup / teardown used for all the bundled unit tests... even that is suspect (but not slavishly disallowed) for WET, because the tests are now entangled with the setup and teardown, making them harder to maintain.
As far as "write everything twice"...
My tipping point for refactoring something used to be "third times the charm". If I had the same logic in three or more places in the code, I'd take some time to refactor that to a single helper routine.
I changed my mind later to more faithful DRY, when the same logic in two different parts of the code (not my code, but the same sentiment) had the same bug, and another developer fixed the bug in one of the two duplicate parts of the code.
The unfixed bug in the other code path probably cost the company upwards of ten million dollars.
An expensive lesson on someone else's dime.
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.
I've heard the acronym in this context:
DRY • Don't Repeat Yourself
for code, but...
WET • Write Expressive Tests
for unit tests.
Meaning that unit tests should be independent of one another, self-contained, and not entangled with other tests, or global state, or unit test order dependent (i.e., the finishing state of one unit test is presupposed as the starting state of a different unit test, so they are implicitly conjoined).
Some unit test frameworks provide a convenient setup / teardown used for all the bundled unit tests... even that is suspect (but not slavishly disallowed) for WET, because the tests are now entangled with the setup and teardown, making them harder to maintain.
As far as "write everything twice"...
My tipping point for refactoring something used to be "third times the charm". If I had the same logic in three or more places in the code, I'd take some time to refactor that to a single helper routine.
I changed my mind later to more faithful DRY, when the same logic in two different parts of the code (not my code, but the same sentiment) had the same bug, and another developer fixed the bug in one of the two duplicate parts of the code.
The unfixed bug in the other code path probably cost the company upwards of ten million dollars.
An expensive lesson on someone else's dime.