의존과 중복
의존성과 중복:
Steve Freeman pointed out that the problem with the test and code as it sits is not duplication (which I have not yet pointed out to you, but I promise to as soon as this digression is over). 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 one vendor’s implementation of SQL scattered throughout 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 symptom. 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 problems in life, where eliminating the symptoms only makes the problem pop up elsewhere in worse form, eliminating 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.