テスト駆動開発は機能作成の最初にテストコードを書き、その後で機能を実現するコードをテストが通るように書く手法で、リファクタリング等の改善が繰り返せる良い繰開発手法です。テストを書かない理由としては時間がないテストを書くのは難しいモチベーションがわかないなどが考えられます。「時間がない」は良く言われる理由です。私の経験ではある程度以上難しい、複雑なアプリの開発ではテストコードを書いた方が早く出来るように思います。テストコードが無いとプログラムの動作確認にアプリの手動操作の繰り返しで無駄に時間を使っていることも多いと思います。次の「テストを書くのは難しい」は事実だと思います、とくにプログラミングの初心者は機能を作るのも精一杯で、その機能をテストするコードを作るのは一筋縄ではいきません。テストコードの書き方にはパターンがあり、初心者レベルを卒業した開発者なら自分が使っている言語・フレームワークで書かれた既存のテストコードを読むことで習得できるのではないかと思います。詰まったり悩んでしまった時に助けてくれるメンターがいないと難しいかもしれません。最後の「モチベーションがわかない」は色々なことが考えられますが、機能の開発は自分で考えたコードの動作を自分で確認できプログラミングの楽しさが感じられる作業です。テストコードは凡庸なコードを並べる事になりがちですし、テストデータの準備など面倒な事も多くモチベーションが下がりがちです。私流のTDDさて私の開発スタイルですが、複雑なロジックやアルゴリズムを持つコードを書くときは素直にTDDで開発します。それ以外の通常のコードを書くときは以下のようになります、アプリ(プロトタイプ)のコードを書くユーザーの評価コードがほぼ固定されたらテストコードの追加テストを書かずに機能等の開発を先に始めます。プロトタイプを開発しユーザーのフィードバックをもらうような開発ではアプリのコードは次々と変わりますし、プロトタイプという事で完成度が低いコードを書くこともあります。繰り返し、コードがほぼ決まってからテストコードを書きます。テストコードは基本的にはリリース前に書くようにしていますが、色々な事情でリリース後になってしまうこともありますが絶対に書くようにしています。テストコードを追加した後ではテストが自動的に行えるようになるのでリファクタリング等が行えるようになります。開発する事が可能になります。既存のコードに手を加えるような変更でもテストコードがあるので、変更の影響も容易に判ります(完璧では無いかもしれませんが)。このように、最初の段階ではテストを書かずに開発し、開発が一段落した後でテストを追加する開発スタイルを私を10年近く行っていますが、ユーザーへの素早リリースと機能追加等のメンテナンス開発時のデグレードの防止に役立っています。テストコードを書き自動テストが出来てしまうと、完璧ではないかもしれないけれどテストが通っているということで自分の書いたコードに自信が持て、リリース直後の不安(プレッシャー)を軽減してくれるのもありがたいです。