One important aspect of tests is to derive them from requirements. Not from the implementation. This is also true if your requirements are only implicit in your

One important aspect of tests is to derive them from requirements. Not from the implementation. This is also true if your requirements are only implicit in your head. TDD ensures this as there is no implementation yet when you write the tests. It also implies the changing requirements comes with the overhead of changing the corresponding tests. This is what happened in the incident described in the article. In many cases development speed might be more important than test coverage. Still worse are tests derived from the implementation (usually to boost done coverage metric) because they often break although the code fulfills the requirements. Rule of thumb: Test only the requirements which are stable.