まずテスト開発駆動(※以下TDD)についてをおさらいです。
TDDはプログラムの開発手法の一つで、以下の略称です。

  • TEST(テスト)
  • DRIVEN(ドリブン：駆動)
  • DEVELOPMENT(デベロップメント：開発)

つまり

  • TEST（テスト）をきっかけに、
  • DRIVEN(ドリブン：駆動)し始める、
  • DEVELOPMENT(デベロップメント：開発)。

といったところでしょうか、

テスト開発駆動(TDD)の他にも「テストファースト」といった言葉も耳にすることが多いと思います。どちらも「テストが先でしょ！！」って事です。

テストを先に必ず書くことで、予期せぬ入力チェック、エラー時の処理などを前もって極限まで減らしていきます。例えば、Ajaxリクエストなどで言うと、ざっと以下のようなケースが考えられます。

  • 正常なデータがレスポンスされた場合
  • エラーのデータがレスポンスされた場合
  • ユーザによりキャンセルされた場合
  • Ajaxで通信エラー起こった場合
  • 通信はエラーで無いが、サーバのプログラムでエラーが起こった場合
  • タイムアウトが起こった場合

とても優秀なデベロッパならこういったケースを全て掌握して、テストを書かずとも全てハンドリングして実装することも可能かもしれません。
しかし普通はどうしても漏れるケースがどうしても出てくるのです、そこでテストプログラムを書くことによって、少し離れた位置からコードを見ることができて、上記のようなケースをもれなくテスト（ハンドリング）することが出来ると思います。

※上記はあくまでデベロッパ単体での開発を想定しています。本来はPM、ディレクター、UXデザイナー、ユーザも含めた上で作られた、設計書なりユースケースがあり、それを踏襲した上でテストケースは考えていく必要がありそうです。