I admire Bob Martin's Clean Code. Lately, however, I realized an apparent contradiction.

One of the three rules of TDD, which Bob Martin advocates for in his book, is to never write more code that is necessary to get your tests pass

But that strongly assumes each app requirement is translatable into a test assertion which isn't the case

Take clean code, for instance. Tests don't care how many things your functions do, how many things your classes do. Refactoring (cleaning) code often involves writing more code – code that is not necessary for your tests. It could be extracting a smaller function or extracting a whole new class. Strictly speaking, even renaming a variable or method is writing more code if the new name is longer (even if it makes the code more readable and cleaner)

So at the end of the day, you have to either

• ditch TDD
• ditch every non-testable requirement (such as clean code)

Since TDD is a PITA anyway, the choice seems to be an easy one

Am I wrong and the two can coexist?

I admire Bob Martin's Clean Code. Lately, however, I realized an apparent contradiction.

One of the three rules of TDD, which Bob Martin advocates for in his book, is to never write more code that is necessary to get your tests pass

But that strongly assumes each app requirement is translatable into a test assertion which isn't the case

Take clean code, for instance. Tests don't care how many things your functions do, how many things your classes do. Refactoring (cleaning) code often involves writing more code – code that is not necessary for your tests. It could be extracting a smaller function or extracting a whole new class. Strictly speaking, even renaming a variable or method is writing more code if the new name is longer (even if it makes the code more readable and cleaner)

So at the end of the day, you have to either

• ditch TDD
• ditch every non-testable requirement (such as clean code)

Since TDD is a PITA anyway, the choice seems to be an easy one

Am I wrong and the two can coexist?