良かったと感じたこと

テストコードを書くから当たり前だけど、コードを修正して動作が正しくなったかどうかの検証が自動でできるのですごく楽。
とくに今回は結果が人には認識し辛い文字列（twitter idとかハッシュ値っぽい値が含まれたurlとか）なので良かったかもしれない。

テストコードが簡単な使い方のサンプルになっているのですぐに思い出せる。

常にテストが通っている状態なので安心感がすごい。

テスト駆動開発を行うためにtwitter apiのシミュレーターを用意する必要があった。 ※実際のapiを使うと結果が変動するため結果比較できない。

apiシミュレーターを作った事でapi返却値を自由に設定できるようになり、 apiが返してくるレアケースな結果に対する機能開発もスムーズに行えた。

たぶんこれがテスト駆動開発の真骨頂なのだと思うが、機能開発をインターフェースから行うことになるので使いやすいインターフェースになり、また単機能毎に開発を行っていく事になるのでいい感じに疎結合な作りになった。

とくにtwitter apiに直接依存しなくなったのでapiシミュレーターに入れ替えたり、必要があれば別のapiに切り替えることもできるような作りになった。

いままでの自分ならたぶんこういう作りにはしていなかったと思う。まさにテスト駆動開発に導かれた設計だと思う。

良くないと感じたこと

「テストが通っているから」と細かい値を見ていなかったら、実は「テスト自体が間違っていた」というパターンがあった。しばらく気づかずに突き進んでしまう場合がある。

テスト駆動の初期は今まで行っていなかった作業（テストを書いたり、テストをしやすい構造にするために悩んだり）が発生するので、その分時間がかかった。

特にapiシミュレーターは、ちゃんと作らないとテスト結果自体が信用出来ないものになるため時間をかける必要があった。

その間機能開発はまったく進んでいないので気持ち的にあせった。

とはいえ、後半はやはり楽になったし、今までは本来必要な作業をすっ飛ばして初動だけスピードを得ていただけなのかもしれない。