TL;DR

The purpose of the unit test is to help the author to remember how production code works, or to help another developer to follow author code design mind thread. Unit-test code should answer question Why we have this method, not How this method works. It also must not make an additional burden to the developer regarding the maintainability of this test codebase. This is the reason why not all production code base practices should be applied to unit test code.

Lets set some context. A unit test is a code written in a unit testing framework, where the unit is a method of a class or module (in a functional programming language). So test exercises a method.

With this context, we guarded the test codebase to not become a monster. In this context, we prefer test code readability over maintenance. We do not need to have DRY code, because this damages code readability. We use DRYness from the production code. If we need some overlord method that uses several production DRY methods, this is a signal that we crossed our unit boundary.

Google ToT series nicely summarizes DAMP (Descriptive And Meaningful Phrases) over the DRY (Do Not Repeat Yourself) principle in Testing on the Toilet: Tests Too DRY? Make Them DAMP!

I noted that using DAMP over DRY will makes us to DUMP existing tests that fail, and make us write a new testing code. Which is ok, because we need a readable test code, not DRY or SOLID one.