僕も最近は正常系から書くことが多いです。こうすると悪い設計に早く気付きやすいという利点があると感じています。 ここでは単体テストのような開発者向けのテストを想定していて、E2Eテストのようなテストでは必ずしも当てはまらないでしょう。
最初にテストを書く時には何も準備がない状態から始まりますが、その時にとても素朴な異常系から始まると整える事前条件が少なく済んで簡単に書けた、という体験になると思います。
そこからインクリメンタルに事前条件を積み重ねて、複雑なメソッドの動作を確かめていきますが、その場合の開発体験はコピペしつつちょっとずつ整えていくという風になり、都度の負担はそれほど高くならないでしょう。
一方、最初に正常系から書く場合、あらゆる事前条件を把握し、それを整えるコードを書く必要があります。
理想的に実装されたメソッドは、どちらの進め方であっても体験は大きく変わらないでしょう。 でも最初からうまくいくことは稀だしインクリメンタルに良くしていくためのハーネスとしてテストがあるので、ひどい時のことを考えます。 たとえば現在時刻に基づく計算をしているとか、ファイルシステムや外部のAPIに依存していてモックが必要だったりとか。
僕の感覚としては、素朴なケースから始めて徐々に重ねていくボトムアップのやりかたでテストを書いていくと、こういったテスタビリティの低い実装に対する感度が鈍るのではないかという仮説を持っています。
テストを書いていって大変だった度が同じ100のメソッドのテストを書くことを考えて、最初にあらゆる事前条件を把握して書く場合は100の大変だった度を感じることになる一方、ボトムアップだと10の大変だった度が10回繰り返されますが、総合的な大変だった度は異なるのではないか、ということです。
なので、最初にひどい目に遭う蓋然性の高いところから書くことで、これはまずい! という感覚を鋭敏に向けられるのでよりよい実装を得やすいのではないか、という意見です。
