コードの正確さを証明できる場合、テストを作成する必要がありますか？

「TDDについて話すことはほとんど効果がありません。誰かにTDDを説得したい場合は、結果を示してください」と人々は言います。ただし、TDDがなくても、すでにすばらしい結果が得られています。TDDを使用する人が良い結果を得ることが納得できないことを私に示すと、TDDとTDD以外の両方を書く人がTDDでより良い結果を得ることができるようにしたいと思います。

これらすべてにもかかわらず、私はTDDを試してみたいと思っています。しかし、私はこれから何かを得るとは確信していません。それが有用であることが判明した場合、私はそれを私のチームの他のメンバーにプッシュしようとします。

私の主な質問は次のとおりです。コードの正確さを既に証明できる場合、TDDはコードに何らかの目的を果たしますか？

明らかに、どちらも特効薬ではありません。詳細を逃したために証拠が間違っている可能性があり、テストでは、テストに失敗したバグを特定できない可能性があります。結局、私たちは人間であり、誰もが100％バグのないコードを永遠に作ることはできません。私たちはできるだけ近づくように努力することができます。

しかし、TDDは、その正確性が証明されたコードの時間を実際に節約するでしょうか？つまり、コードが動作するステートマシンで、有効なすべての状態とその範囲が開発者によって認識され、すべてが考慮され、コードがすべての例外を渡すホワイトリストスタイルのエラーチェックで設計されているコード予期しないリークがないことを確認するための上位ハンドラー->（理由内の）関連メッセージをクライアントに表示することも、ログ通知を管理者に送信することもありません。

実際の例での回答の方が良いでしょう。

いくつかの説明：

• この質問は、コードの正当性を証明できるかどうかについてではありません。デフォルトでは、すべてのコードが妥当な時間枠内で正しいことが証明できるとは限らないが、一部のコードはそうであると想定します。たとえば、FizzBu​​zzモジュールの正当性を証明するのは非常に簡単です。クラウドベースのデータ同期サービスではそれほど簡単ではありません。

• この制限内では、質問は次のように尋ねます。コードベースが2つの部分に分割されているという仮定から始めます。[I]正しいことが証明されている部分[II]正しく証明されていないが、手動で動作するようにテストされている部分。

• 今までTDDプラクティスがなかったこのコードベースにTDDプラクティスを適用したいと思います。質問は次のように質問します。TDDはすべての単一のモジュールに適用する必要がありますか、それとも、正しくないことが証明されたモジュールにのみ適用すれば十分でしょうか。

• 「実証済み」とは、このモジュールを完全に機能的なスタイルと見なすことができることを意味します。つまり、このモジュールは外部のグローバルまたは外部状態に依存せず、やり取りする他のモジュールが従う必要のあるI / O用の独自のAPIを完全に備えています。 。モジュールの外のコードを変更して「このモジュールを壊す」ことはできません。最悪の場合、コードを誤用して、フォーマットされたエラーメッセージを返す可能性があります。

• 明らかに、すべてのルールには例外があり、新しいコンパイラバージョンのコンパイラバグはこのモジュールにバグをもたらす可能性がありますが、同じバグがそれをテストしたテストに導入され、意図したとおりに機能しなくなったテストから誤った安全性をもたらす可能性があります。つまり、テストは魔法のようなソリューションではなく、保護の別のレイヤーであり、この質問は、この保護のレイヤーが、正しいことが証明されたモジュールの特定のケースで努力する価値があるかどうかの問題について説明します（それは確かに）でした。

はい。

プルーフは利用可能であれば問題ありませんが、最良の場合でも、コードの1ビットが期待どおりに機能することを証明するだけです（すべての入力に対して？処理の途中での中断を考慮して？）メモリ不足について？ディスク障害？ネットワーク障害？）。

変更するとどうなりますか？

テストはコードが何をすべきかについての暗黙の契約として役立つので素晴らしいです。彼らは足場を提供するので、あなたの新しいインターンは、ある程度の自信を持って入り、変更を加えることができます。すべて迅速かつ明確な結果を介して：合格または不合格。

そして率直に言って、私はインターンを指導して、数か月で実行可能な単体テストを書くことができます。私のチーム（私も含む）の誰もが、重要なコードにとって意味のある何かを保証する証明を作成できるとは思えません。言うまでもなく、迅速かつ正確にそれを行います。

わかりません。ご質問にはお答えできません。

あなたが多くの時間を費やして、あなたが今しているプロセスが誰もが満足するように機能しているように思われる一方で、実際に何が起こっているかをほんの少しだけ伝えています。

私の経験から、あなたが説明しているのは非常に珍しいことであり、実際にアプリケーションのバグ数が少ない原因は、実際のプロセスとコーディングへのアプローチであることに懐疑的です。あなたのアプリケーションに影響を与える他の多くの要因があるかもしれません、そしてあなたはそれらの要因について私たちに何も言っていません。

したがって、TDDが役立つかどうかは、正確な開発環境と文化を知らないということを前にしてわかりません。そして、それについて何日も議論し、議論することができます。

お勧めできるアドバイスは1つだけです。それをお試しください。実験。勉強しなさい。私はあなたが決定するために最小限の努力を費やそうとしていることを知っていますが、それは不可能です。TDDがコンテキストで機能するかどうかを本当に知りたい場合、実際にTDDを実行することが唯一の方法です。実際にそれを学び、アプリケーションに適用する場合、それを非TDDプロセスと比較できます。TDDには実際に利点があり、それを維持することにした可能性があります。または、TDDは何も新しいものをもたらさず、あなたを遅くするだけであることが判明する可能性があります。その場合、以前のプロセスにフォールバックできます。

（ユニット）テストの主な目的はコードを保護することであり、後の変更のために気付かれずにコードが壊れないようにします。コードが最初に書かれたとき、それは多くの注目を集め、精査されます。そして、あなたはそのためのいくつかの優れたシステムを持っているかもしれません。

6か月後、他の誰かが一見無関係なものに取り組んでいるとき、それは壊れる可能性があり、スーパーデューパーコードの正確性プロバイダーはそれに気付かないでしょう。自動テストします。

今までTDDプラクティスがなかったこのコードベースにTDDプラクティスを適用したいと思います。

これがTDDを学ぶ最も難しい方法です。テストが遅れるほど、テストの作成にかかるコストが高くなり、テストを書く手間が減ります。

テストを既存のコードベースに組み込むことが不可能だと言っているのではありません。そうすることで、誰もがTDD信者になる可能性は低いと言っています。これは大変な作業です。

新しいものや家庭で初めてTDDを練習するのが実際には最善です。そのようにして、あなたは本当のリズムを学びます。これを正しく行うと、中毒性があります。

質問は次のことを尋ねます：TDDがすべての単一のモジュールに適用されるべきか、

それが構造的思考です。すべての関数、クラス、モジュールをテストするようなことを言うべきではありません。これらの境界はテストにとって重要ではなく、とにかく変更できるはずです。TDDは、テスト可能な行動ニーズを確立することであり、それがどのように満たされるかを気にすることではありません。そうでなければ、リファクタリングできませんでした。

それとも、正しく証明されなかったモジュールのみに適用するだけで十分でしょうか？

必要に応じて適用すれば十分です。新しいコードから始めます。あなたはテストを遅くするよりも早くテストすることでより多くを取り戻すでしょう。あなたが家でそれを習得するのに十分な練習をするまで、仕事でこれをしないでください。

新しいコードが機能していてTDDが効果的であり、古いコードを引き継ぐのに十分な自信があることを示したら、実証済みのコードから始めます。その理由は、作成しているテストがコードを適切な方向に進めているかどうかをすぐに確認できるからです。

私の主な質問は次のとおりです。コードの正確さを既に証明できる場合、TDDはコードに何らかの目的を果たしますか？

テストは正しさを証明するだけではありません。彼らは意図を示しています。彼らは必要なものを示しています。彼らは変化への道を指摘しています。優れたテストでは、このコードを記述して必要なものを取得する方法はいくつかあるとしています。新しいコーダーがすべてを壊すことなく何ができるかを確認するのに役立ちます。

一度それがダウンしたら、証明されていないコードにさまようべきです。

熱心な人々への警告：あなたは成功を収めたように聞こえるので、頭から飛びつくことはまずありません。しかし、彼ら自身を証明しようとしている他の人はそれほど控えめではありません。TDDはやり過ぎることがあります。トライバルで意味のないものをロックダウンするため、実際にリファクタリングを損なう一連のテストを作成するのは驚くほど簡単です。これはどのように起こりますか？テストを自慢して見たい人はテストを書くだけでリファクタリングをしないからです。解決？それらをリファクタリングします。機能の変更に対応してもらいます。早いほど良い。これは、役に立たないテストをすばやく表示します。屈曲することで柔軟性を証明します。

構造的分類に対する警告：クラスはユニットであると主張する人もいます。2つのクラスを含むテストを統合テストと呼ぶ人もいます。境界xを越えてユニットテストと呼ぶことはできないと主張する人もいます。テストの動作に注意することをお勧めします。ほんの一瞬で実行できますか？他のテストと並行して実行できますか（副作用なし）？依存関係と前提条件を満たすために、他のものを起動したり編集したりせずに実行できますか？DB、ファイルシステム、またはネットワークと通信する場合は、これらの考慮事項を優先します。どうして？これらの最後の3つは、他の問題の原因となるため、単なる問題です。テストの動作をどのように期待できるかに基づいて、テストをグループ化します。彼らがたまたま越えた境界ではありません。次に、各テストスイートに何を期待できるかを理解します。

オーバーヘッドが多すぎるためTDDを使いたくないと人々が言っ​​ているのを見てきました。TDDの支持者は、TDDの記述に慣れれば、オーバーヘッドはほとんどないと言って防御しています。

その質問にはすでに回答があります。

テスト駆動開発は、テストよりも、APIのプロトタイピングとブレーンストーミングについてです。多くの場合、作成されたテストは質が低く、最終的には破棄する必要があります。TDDの主な利点は、API実装を記述する前に、APIの使用方法を決定することです。この利点は、他の方法でも得られます。たとえば、実装前にAPIドキュメントを作成することで得られます。

正当性の証明は、常にテストよりも価値があります。テストは何も証明しません。ただし、正確性の証明を生産的に使用するには、自動化された証明チェッカーが役立ち、何らかの契約（契約による設計または契約ベースの設計）を使用して作業する必要があります。

以前は、コードの重要なセクションで作業するとき、手動で正当性を証明しようとしました。非公式の証明であっても、自動テストよりも価値があります。しかし、人々が将来あなたのコードを壊すので、証明を自動化できない限り、あなたはまだテストが必要です。

自動テストはTDDを意味しません。

A）コードを読んで、それが正しいことを納得させると、それが正しいことを証明することにはほど遠くはありません。そうでなければ、なぜテストを書くのですか？

B）コードを変更する場合、コードがまだ正しいかどうかを示すテストを実行する必要があります。

TDDを効果的に使用することに慣れると、エンドゲームの時間を節約できると言って、警告します。TDDを効果的に使用する方法を学ぶには練習が必要であり、時間の危機に瀕しているときには役に立ちません。それを最大限に活用する方法を学ぶときは、より多くの余裕があり、スケジュールのプレッシャーが少ない個人的なプロジェクトから始めることをお勧めします。

より多くの実験を行い、APIを作成している間は、初期の進行が遅いことがわかります。時間の経過とともに、コードを変更せずに新しいテストに合格し始め、ビルドするベースが非常に安定しているため、進捗が速くなります。後半のゲームでは、TDDを使用してビルドされていないコードでは、何が問題であるかを理解するために必要以上に多くの時間をデバッガーで費やす必要があります。また、以前は新しい変更で機能していた何かを壊すリスクが高まります。 TDDの有効性を、使用しない場合と比較して、完了までの合計時間で評価します。

そうは言っても、町で唯一のゲームはTDDではありません。フルスタックアプリケーションの動作を表現する標準的な方法を使用するBDDを使用し、そこからAPIの正確性を評価できます。

議論全体が「コードの正確さの証明」にかかっているため、コードの正確さを定義するものが必要です。「正しい」の意味を定義するために自動化ツールを使用していない場合、定義は非常に主観的です。正しい定義が仲間のコンセンサスに基づいている場合、それはいつでも変わる可能性があります。正しい定義は具体的かつ検証可能である必要があります。これは、ツールで評価できる必要があることも意味します。なぜ使用しないのですか？

＃1の任意の並べ替えの自動テストを使用してからの勝利は、ということであるあなたのコードの遺骨を修正検証できる OSパッチを迅速かつ効率的に適用した場合であっても。スイートを実行してすべてが成功していることを確認してから、パッチを適用してスイートを再度実行します。さらに、自動ビルドインフラストラクチャの一部にします。これで、複数の開発者のコ​​ードをマージした後も、コードが正しいことを確認できます。

TDDを使用した経験から、次のような結論に至りました。

• 新しいコードには最適ですが、レガシーシステムの変更は困難です
• あなたはまだ自分が達成しようとしていることを知る必要があります（つまり計画を持っている）
• 開始が遅いが、後で時間を節約できる
• ユーザーの観点から正確性とデバッグを検証する方法を考えるように強制します

BDDを使用した経験から、次のような結論に至りました。

• 従来のコードと新しいコードの両方で機能します
• スタック全体を検証し、仕様を定義します
• 立ち上がるのに時間がかかる（ツールセットを知っている人がいるのに役立ちます）
• 単体テストよりも少ない動作を定義する必要があります

正しい定義：コードは要件に準拠しています。これはBDDで検証するのが最適です。BDDは、人間が読める形式で要件を表現し、実行時にそれらを検証する手段を提供します。

私は数学の証明という点で正しさについて話しているわけではありませんが、それは不可能です。そして、私はその議論をすることにうんざりしています。