My thesis: given two design which accomplish the same thing, the one which requires fewer tests is a better design. This I believe to be true from either a Quality Assurance (QA) point of view, or a TDD point of view. This is why I say that we want to somehow strive towards elimination of tests in our designs. When it is possible to forecast the number of tests required for a design decision, in theory it should make it easier to make design choices. Perhaps this could lead to software which makes design decisions, though this is probably pretty far out there.

My previous conflation of TDD and QA was somewhat intentional, because I think that QA is automatically a goal of any programmer, and any methodology. I assert that the biggest advantage of TDD by itself is QA through incidental correctness testing.

A development methodology in of itself is useless, unless it helps us achieve our goal as programmers:

Writing correct software in the shortest amount of time.

class string {
  public {
    concat(string s) : string {
      // postconditions
      after {
        ?(result.count() == count() + s.count());
        for (int i=0; i < count(); ++i) {
          ?(result[i] == this[i]);
        }
        for (int i=0; i < s.count(); ++i) {
          ?(result[i + result.count()] == s[i]);
        }
      }
      // implementation
      ....
    }
    reverse(string s) : string {
      // postconditions
      after {
        ?(result.count() == count());
        for (int i=0; i < count(); ++i) {
          ?(result[i] == this[(count() - 1) - i]);
        }
      }
      // implementation
      ...
    }
    trivial_concat_reverse(string s) : string {
      // testing not-needed
      // trivial implementation
      return concat(reverse(s));
    }
    optimized_concat_reverse(string s) : string {
      after {
        ...
      }      
      // non-trivial implementation
      ...
    }
  }
}