Steve Freeman pointed out that the problem with the test and code as it sits is not duplication. The problem is the dependency between the code and the test - you can't change one without changing the other. Our goal is to be able to write another test that "makes sense" to us, without having to change the code, something that is not possible with the current implementation.
Dependency is the key problem in software development at all scales. If you have details of vendor's implementation of SQL scattered throughout the the code and you decide to change to another vendor, then you will discover that your code is dependent on the database vendor. You can't change the database without changing the code.
If dependency is the problem, duplication is the sympton. Duplication most often takes the form of duplicate logic - the same expression appearing in multiple places in the code. Objects are excellent for abstracting away the duplication of logic.
Unlike most problem in life,where eliminating the symptons only makes the problem pops up elsewhere in worse form, eliminating the duplication in programs eliminates dependency. That's
why the second rule appears in TDD. By eliminating duplication before we go on to the next test, we maximize our chance of being able to get the next test running with one and only one change.
Kent Beck - 2004
