For the purpose of clarification, we are defining optimization as anything that obfuscates the code, making it less clear or more difficult to understand, or anything that limits the possibilities further than the test requires. A premature optimization is an optimization that is done for any reason other than specified by a requirement.

Typically, optimizations are done using performance as an excuse. Before these types of modifications of the code are done, a requirement specifying the need for the change should exist.

Even through the practice of Test-Driven Development, it is possible to paint yourself into a corner. Often during refactoring or during the process of designing your next test, it is possible to solve too much of the problem at once or refactor too much. 

Always keep in mind that, in TDD, we want to break a problem down into the smallest steps possible. Also, don't go for the solution in the first test if the solution is more than a line or two. At the same time, even for small solutions, if the solution is calculation or algorithm heavy, it should still be broken down, even if the eventual solution is a single line of production code.

Refactoring, according to Kent Beck, is the process of removing duplication. Remember that while refactoring your tests. By only removing duplication, we can avoid premature optimization via refactoring. It is completely possible, and even attractive at times, to refactor a solution and reduce the code significantly, or even to use a fancy new language feature or Linq expression to make your test pass. These solutions are fine in the long run, but while the tests are still being built, these hidden optimizations can cause you and your tests to become derailed extremely quickly.