私が行ったコードのほとんどについて単体テストを作成しましたが、ケント・ベックの例でTDDのコピーを入手したのはつい最近のことです。アプリケーションを「テスト可能」にすることができなかったため、私が行った特定の設計上の決定を常に後悔しています。私はこの本を読みましたが、一部は異質に見えますが、それを管理できると感じ、基本的に2つの部分が通信するクライアント/サーバーシステムである現在のプロジェクトで試してみることにしました。USB。1つはガジェットに、もう1つはホストにあります。アプリケーションはPythonです。
私は始めてすぐに、書き直しの混乱と小さなテストに巻き込まれましたが、後で実際には何もテストされていないと思いました。私はそれらのほとんどを捨てました、そして今、テストがすべてたった2つに凝固した実用的なアプリケーションを持っています。
私の経験に基づいて、私が聞きたいいくつかの質問があります。NewからTDDまでいくつかの情報を入手しました：TDDの実行方法を示すテスト付きのサンプルアプリケーションはありますか？しかし、私が答え/議論したいいくつかの特定の質問があります。
- Kent Beckは、開発プロセスをガイドするために、彼が追加および削除したリストを使用します。どのようにしてそのようなリストを作成しますか？最初は「サーバーを起動する必要がある」、「チャネルが利用できない場合はサーバーを中止する必要がある」などの項目がいくつかありましたが、それらは混ざり合い、最終的には「クライアントがサーバーに接続できる必要があります」のようなものになりました。包含サーバーの起動など）。
- 書き換えはどのように処理しますか？最初は名前付きパイプに基づく半二重システムを選択したので、自分のマシンでアプリケーションロジックを開発し、後でUSB通信部分を追加できました。それらはソケットベースのものに移行し、次にrawソケットの使用からPythonSocketServerモジュールの使用に移行しました。状況が変わるたびに、面倒なテストのかなりの部分を書き直さなければならないことに気づきました。私は、テストが私の開発中にいくぶん不変のガイドになるだろうと考えました。彼らは、処理するコードが増えたように感じました。
- どちらかの側をテストするために、チャネルを介して通信するためのクライアントとサーバーが必要でした。片方をモックしてもう片方をテストすることはできましたが、チャンネル全体がテストされなかったので、それを見逃してしまうのではないかと心配しています。これは、赤/緑/リファクタリングのリズム全体を損ないました。これは単に経験不足ですか、それとも私は何か間違ったことをしていますか？
- 「あなたがそれを作るまでそれを偽造する」は私にたくさんの厄介なコードを残しました、そしてそれは後で私がリファクタリングとクリーンアップするために多くの時間を費やしました。これは物事が機能する方法ですか？
- セッションの最後に、クライアントとサーバーを約3〜4個の単体テストで実行しています。それをするのに約1週間かかりました。コードの後に単体テストを使用していれば、1日でそれを実行できたと思います。ゲインがわかりません。
この方法論を使用して、大規模で重要なプロジェクトを完全に（またはほぼ完全に）実装した人々からのコメントとアドバイスを探しています。すでに何かを実行していて、新しい機能を追加したい場合は、その方法に従うのが理にかなっていますが、最初からそれを行うのは面倒で、努力する価値がないようです。
PS：これがコミュニティウィキであるかどうかを教えてください。そのようにマークします。
更新0：すべての回答が等しく役に立ちました。自分の経験に最も共鳴したので、自分がやったものを選びました。
アップデート1：練習練習練習！