私はちょうどCSの学位を取得して卒業しましたが、現在はジュニア.NET開発者（C＃、ASP.NET、およびWebフォーム）として仕事をしています。私がまだ大学にいたとき、ユニットテストの主題はカバーされましたが、その利点は実際には見られませんでした。コードのブロックが使用に適しているかどうかを判断する、つまり、何をすべきかを理解しています。しかし、私は実際に単体テストを書く必要がなかったし、その必要性を感じたこともありませんでした。

既に述べたように、私は通常ASP.NET Webフォームを使用して開発しており、最近、いくつかの単体テストを作成することを考えています。しかし、これについていくつか質問があります。

ユニットテストは、しばしば「モック」を書くことで行われることを読みました。私はこの概念を理解していますが、完全に動的なWebサイトのモックをどのように作成し、ほとんどすべてがデータベースからのデータに依存するかを理解することはできません。たとえば、私はItemDataBoundイベントなどを持っているリピーターをたくさん使用しています（これも「不明」なデータに依存します）。

質問番号1：ASP.NET Webフォームのユニットテストを書くことは頻繁に行われますが、もしそうなら：「動的環境」問題をどのように解決すればよいですか？

私が開発しているとき、私は多くの試行錯誤を繰り返します。だからといって、自分が何をしているのかわからないというわけではありませんが、通常はコードを書いて、Ctrl F5何が起こるかを確認します。ほとんどの場合、このアプローチは仕事をしますが、時々、私は少し無知であると感じます（私の小さな経験のため）。私も時々このように多くの時間を無駄にします。

質問番号2：ユニットテストの書き始めをアドバイスしてくれませんか？実際の実装には役立つかもしれないと思いますが、それでも私は遅くなるかもしれないと感じています。

私の意見では：はい、そうです、そうです。

1. 彼らはあなたが行う変更に自信を与えます（他のすべてはまだ機能しています）。この自信は、コードを成形するために必要なものです。さもないと、物事を変えることを恐れるでしょう。

2. コードを改善します。最も単純な間違いは、ユニットテストで早期に発見されます。バグを早期に発見して修正することは、たとえばアプリケーションが実稼働中の場合など、後で修正するよりも常に安価です。

3. これらは、コードの仕組みと使用方法に関する他の開発者向けのドキュメントとして機能します。

最初に直面する問題は、ASP.NET自体は単体テストの作成に役立ちません。実際には、ASP.NETは機能しません。選択肢がある場合は、単体テストを考慮して作成されたASP.NET MVCの使用を開始してください。ASP.NET MVCを使用できない場合は、少なくともロジックを簡単にユニットテストできるように、ASP.NETでMVPパターンを使用する必要があります。

それに加えて、単体テストの作成に習熟する必要があります。TDDを実践すれば、コードはテスト可能に作成されます。つまり、すてきできれいです。

私はあなたに練習し、ペアプログラムを勧めます。読んでいる間：

• アジャイルソフトウェア開発、原則、パターン、および実践[ハードカバー]
• ヘッドファーストデザインパターン
• GOFデザインパターンバイブル
• Roy osheroveによるユニットテストの最初の紹介
• ユニットテストパターンバイブル

または、最初の概要：

• 固体
• Xunitテストパターン

番号。

単体テストの背後にある概念は、単体テストが発明される前から間違っていることが知られている前提に基づいています。つまり、テストはコードが正しいことを証明できるという考え方です。

すべてが合格するテストがたくさんあるということは、1つのことと1つのことだけを証明します。すべてが合格するテストがたくさんあるということです。テストがテストしているものが仕様と一致することを証明しません。テストを書いたときに考えたことのないエラーがコードにないことを証明するものではありません。（そして、あなたがテストしようと考えていたものは、あなたが焦点を当てていた可能性のある問題だったので、とにかくそれらを正しかったと思われます！）バグがない。（最後の説明に従って論理的な結論を下すと、最後までカメになってしまいます。）

Djikstra は1988年に「正当性の証明としてのテスト」という概念を破棄しましたが、彼が書いた内容は今日でも有効です。

プログラムのテストではバグの存在を説得力のある形で示すことができるが、バグがないことを示すことはできないと指摘されてから20年になります。このよく知られた発言を熱心に引用した後、ソフトウェアエンジニアはその日の順序に戻り、クリソコスミックな精製を洗練し続けた昔の錬金術師のように、テスト戦略を洗練し続けます。

単体テストのもう1つの問題は、コードとテストスイートの間に密結合が生じることです。コードを変更すると、いくつかのバグが表示され、いくつかのテストが失敗することが予想されます。ただし、要件自体が変更されたためにコードを変更する場合、多くの失敗したテストが発生し、各テストを手動で確認して、テストがまだ有効かどうかを判断する必要があります。（また、あまり一般的ではありませんが、変更が必要なものを変更するのを忘れたために、無効である必要がある既存のテストに合格する可能性もあります。）

単体テストは、実際に優れたプログラマーでなくても作業コードを簡単に記述できるようになることを約束する開発の流れの最新のものです。彼らの誰も彼らの約束を果たすことができなかったし、これもそうしなかった。実際に動作するコードの書き方を知るための近道はありません。

自動化されたテストは、安定性と信頼性が最も重要な場合に真に役立つという報告がいくつかあります。たとえば、SQLiteデータベースプロジェクト。しかし、信頼性のレベルを達成するために必要なことは、ほとんどのプロジェクトにとって非常に不経済です。テストと実際のSQLiteコードの比率はほぼ1200：1です。ほとんどのプロジェクトはそれを買う余裕がなく、とにかくそれを必要としません。

学校向けの小さなコードをテストするためのメインメソッドを作成する利点をこれまでに見たことがあれば、ユニットテストは同じプラクティスのプロフェッショナル版/エンタープライズ版です。

また、コードのビルド、ローカルWebサーバーの起動、問題のページの閲覧、データの入力または適切なテストシードへの入力の設定、フォームの送信、結果の分析のオーバーヘッドを想像してください...ビルドとヒットnUnit実行ボタン。

こちらも楽しい画像です...

ここでこの画像を見つけました：http :
//www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/

ユニットテストは最近、それについて何か神秘的です。100％のテストカバレッジが聖杯であるかのように、また単体テストがソフトウェア開発の1つの真の方法であるかのように、人々はそれを扱います。

彼らはポイントを逃しています。

単体テストは答えではありません。 テストです。

さて、この議論が起こるたびに、誰か（私でさえも）がダイクストラの引用を無視します：「プログラムのテストはバグの存在を示すことができますが、バグがないことを示すことはありません。」ダイクストラは正しい。テストは、ソフトウェアが意図したとおりに機能することを証明するには不十分です。しかし、それは必要です。あるレベルでは、ソフトウェアがあなたが望むことをしていることを実証することが可能でなければなりません。

多くの人が手でテストします。頑固なTDD愛好家でさえ手動テストを行いますが、認めないこともあります。仕方がありません。ソフトウェアをクライアント/ボス/投資家などにデモするために会議室に行く直前に、それが動作することを確認するために手作業で実行します。それには何の問題もありません。実際、100％の単体テストのカバレッジとテストに最大限の自信がある場合でも、手動で実行せずにすべてをスムーズに実行すること（つまり、テストすること）を期待するのはおかしいでしょう。

ただし、ソフトウェアのビルドに必要であっても、手動テストで十分なことはめったにありません。どうして？手動テストは退屈で時間がかかり、人間が実行するためです。そして、人間は退屈で時間のかかるタスクを実行することで悪名が高いことで知られています。

一方、マシンは、退屈で時間のかかるタスクの実行に優れています。結局のところ、それがコンピューターが発明された理由です。

そのため、テストは非常に重要であり、自動テストは、テストが一貫して採用されることを保証する唯一の賢明な方法です。そして、ソフトウェアが開発されるにつれて、テストし、再テストすることが重要です。ここでの別の答えは回帰テストの重要性に注意します。ソフトウェアシステムは複雑であるため、システムのある部分に対する一見無害な変更が、システムの他の部分に意図しない変更（バグ）を引き起こすことがよくあります。何らかのテストを行わないと、これらの意図しない変更を発見することはできません。また、テストに関する信頼できるデータを取得するには、体系的な方法でテストを実行する必要があります。つまり、何らかの自動テストシステムが必要です。

これはすべて単体テストと何の関係がありますか？まあ、その性質上、単体テストは人間ではなくマシンによって実行されます。そのため、多くの人は、自動化されたテストが単体テストに等しいという誤った印象を受けています。しかし、それは真実ではありません。ユニットテストは、非常に小さな自動テストです。

さて、非常に小さな自動テストの価値は何ですか？利点は、彼らがソフトウェアシステムのコンポーネントをテストすることである分離でき、より正確な試験の標的、およびデバッグに助。しかし、単体テストは本質的に高品質のテストを意味するものではありません。多くの場合、ソフトウェアをより詳細なレベルでカバーするため、テストの品質が向上します。ただし、複合部品ではなく、完全なシステムのみの動作を完全にテストし、それでも完全にテストすることは可能です。

しかし、100％の単体テストの範囲であっても、システムはまだ完全にテストされていない場合があります。個々のコンポーネントは単独で完全に動作する可能性がありますが、一緒に使用すると失敗します。そのため、単体テストは非常に便利ですが、ソフトウェアが期待どおりに動作することを確認するには不十分です。実際、多くの開発者は、自動化された統合テスト、自動化された機能テスト、および手動テストでユニットテストを補完しています。

単体テストに価値が見られない場合は、おそらく別の種類の自動テストを使用することから始めるのが最善の方法です。Web環境では、Seleniumのようなブラウザ自動化テストツールを使用すると、比較的小さな投資で大きな勝利を得ることができます。つま先を水に浸すと、自動化されたテストの有用性をより簡単に確認できるようになります。自動化されたテストを実行すると、ユニットテストは大きな統合テストやエンドツーエンドテストよりも迅速なターンアラウンドを提供し、現在作業中のコンポーネントのみをテストの対象とすることができるため、はるかに理にかなっています。

TL; DR：単体テストについてはまだ心配しないでください。最初にソフトウェアをテストすることを心配するだけです。

場合によります

これは、ソフトウェア開発に関して多くのことを知る答えです。しかし、単体テストの有用性は、それらがどれだけうまく書かれているかに本当に依存します。回帰テストのためにアプリケーションの機能をチェックする単体テストの名目数は非常に便利です。ただし、関数の戻り値をチェックする多数の単純なテストはまったく役に立たない可能性があり、アプリケーションには「多数の単体テストがある」ため、誤ったセキュリティを提供します。

さらに、開発者としての時間は貴重であり、単体テストの作成に費やす時間は、新しい機能の作成に費やす時間ではありません。繰り返しますが、これはユニットテストを書くべきではないということではありませんが、すべてのパブリック関数にはユニットテストが必要ですか？私は答えがノーだと提出します。ユーザー入力の検証を実行しているコードには単体テストが必要ですか？アプリケーションの一般的な障害ポイントである可能性が非常に高いです。

これは経験が関係する分野の1つであり、時間の経過とともに、単体テストの恩恵を受ける可能性のあるアプリケーションの部分を認識しますが、その時点に達するまでにはしばらく時間がかかります。

大学の授業で行われるプロジェクトは、職場で作成するビジネスアプリケーションとは大きく異なります。違いは寿命です。大学はどのくらいの期間「ライブ」を計画していますか？ほとんどの場合、コードの最初の行を記述すると開始し、マークを取得すると終了します。事実上、それは実装時のみ有効です。「リリース」は通常、「死」に相当します。

ビジネス向けに作成されたソフトウェアは、大学プロジェクトのリリースデスポイントを超え、ビジネスが必要とする限り存続します。これは非常に長いです。お金の話をするとき、誰もが「クールでかっこいいコード」を得るために壊れたお金を費やすことはありません。25年前にCで書かれたソフトウェアがまだ機能し、（ビジネスオーナーのニーズに応じて）十分に機能している場合、それを維持するように求められます（新しい機能の追加、古い機能の改善- ソースコードの変更）。

回帰という非常に重要な点に行き着きます。私が働いている場所には、2つのチームが2つのアプリを管理しています。1つは5〜6年前に書いたもので、コードテストのカバレッジはほとんどありません*、2つ目は本格的なテストスイート（ユニット、統合など）を備えた最初のアプリケーションの新しいバージョンです。どちらのチームにも専用の手動（人間）テスターがいます。最初のチームに新しい基本的な機能を導入するのにどれくらい時間がかかるか知りたいですか？3〜4週間。この時間の半分は「他のすべてがまだ機能しているかどうかを確認する」ことです。これは手動テスターに​​とって忙しい時間です。電話が鳴り、人々は動揺し、何かが再び壊れます。通常、2番目のチームはこのような問題を3日以内に処理します。

私は、ユニットテストがあなたのコードエラーを起こしやすい、正しい、またはあなたが思いつくことができる他の派手な言葉にすることを決して言いません。どちらもバグを魔法のように消滅させません。しかし、自動化されたソフトウェアテストの他の方法と組み合わせると、他の方法よりもはるかに保守しやすくなります。これは大きな勝利です。

最後になりましたが、最後に重要なことですが、ブライアンによるコメントは問題全体を釘付けにしていると思います。

（...）彼らはコードがあなたがそれをするように設計したことをし、明日は今日のことをし続けるというあなたの自信を高めます（またはするべきです...）。

なぜなら、今日から明日までに、誰かが小さな変更を加えることで、非常に重要なレポートジェネレーターのコードがクラッシュする可能性があるからです。テストは、顧客があなたの側に少しやってくる前に、あなたがこれを見つける確率を押し上げます。

_{*彼らは徐々にコードベースにますます多くのテストを導入しますが、私たちは皆、このものが通常どのように見えるかを知っています。}

ASP.NET Webフォームのユニットテストを頻繁に行われていることを書いていますが、そうである場合：「動的環境」の問題をどのように解決しますか？

頻繁には行われません。UI要素の操作は、ユニットテストが得意なものではありません。適切なものが適切な場所の画面に表示されることをプログラムで確認するための優れた方法がないためです。

ユニットテストの書き始めをアドバイスしてくれませんか？実際の実装ではそれが役立つかもしれないと思うが、それでも私は遅くなるかもしれないと感じる。

該当する場合、はい。特定のケースを再現可能な方法で検証するのに非常に役立ちます。それらは、面倒な変更に対する「摩擦」として機能し、より良い変更を行う際のフェイルセーフとして機能します。

注意すべきことの1つは、通常は速度が低下することです。

大丈夫です。

少し時間を費やすことで（うまく行けば）バグをキャッチし、バグの再発を防ぎ、腐敗を防ぐためにコードの他の改善をより快適に行えるようになるため、将来の時間を節約できます。

私はちょうどCSの学位を取得して卒業しましたが、現在はジュニア.NET開発者（C＃および通常ASP.NET、ASP.NET MVCではなくWebフォーム）として仕事をしています。私がまだ大学にいたときに戻って、ユニットテストの主題はカバーされましたが、私はそれの利点を見たことがありませんでした。

それは、あなたが大きくプログラムしたことがないからです。

私はそれが何をすべきかを理解しています-コードのブロックが使用に適しているかどうかを決定します-しかし、実際にユニットテストを書く必要はありませんでした。（また、私は..の必要性を感じたことがありませんでした。）

単体テストを作成すると、コードはテスト可能で、十分に文書化され、信頼できる特定の精神構造に準拠するようになります。それはあなたが主張する以上のものです。

-ユニットテストは「モック」を書くことで行われることが多いと読みました。私はこの概念を理解していますが、完全に動的なウェブサイトのモックをどのように書くべきか、そしてほとんどすべてがデータベースからのデータに依存する場所を理解することはできないようです。

明確に定義されたハードコードされたデータで満たされたモデルクラスを返すモッククラスを使用して、データベースアクセスをモックします。または、テストデータベースにフィクスチャデータを入力し、そこから作業します。

-ユニットテストの作成を開始するようにアドバイスしてもらえますか？

もちろん。最初にベックの「テスト駆動開発」をお読みください。

実際の実装ではそれが役立つかもしれないと思うが、それでも私は遅くなるかもしれないと感じる。

それは今あなたを遅くします。しかし、数日ではなく数時間デバッグする必要がある場合は、気が変わります。

アドバイスをいただければ幸いです:)

テスト。私を信じて。残念ながら、これも管理ポリシーでなければなりませんが、時間を節約するものです。テストは現在も将来も存続します。プラットフォームを変更し、テストを実行してもテストが機能する場合は、自分のものが期待どおりに機能していることがわかります。

編集：もちろん、TDD pro / con dogpileに参加して質問1をスキップしました。

1-ASP.net Webフォームでの単体テストの実装：

まず、MVCを使用してもらうことができると思われる場合は、猛烈な穴居人のようにMVCのために戦ってください。フロントエンド/ UI開発者として、.net MVCは.netを嫌うのを止めるのに役立ちました。そのため、これまでに遭遇したすべてのJava Webソリューションを嫌うことに集中できました。ユニットテストには問題があります。なぜなら、ウェブフォームはサーバーとクライアントサイドの間の境界線を本当に曖昧にしているからです。ユニットテストを実行しようとすると、データ操作に焦点を当て、（できれば）webformsが内部のユーザー入力の正規化を処理すると仮定します。

2-そもそも単体テストが価値があるかどうかについて：

申し分なく、完全開示：

• 私はほとんど独学です。私の正式なトレーニングは、1つのJavaScript、PHP、C＃クラスが好きになり、OOPの原理とデザインパターンのようなものを読むことについての私自身の個人的な研究になります。

しかしながら、

• 私はほとんどクライアント側のWeb向けに書いており、その実際のプログラミング部分は、動的型付け、ファーストクラス関数、オブジェクトの可変性に関して、最も高速で緩い言語の1つです。

つまり、私は同じコンパイラーまたは仮想マシン用に作成しません。私は3つの言語の4-20のさまざまな解釈（そう、そのうちの2つは単に宣言的であるが、時々異なる方法で作業しているUIの基本的な物理空間を決定する）のように書いており、その解釈は今日よりもずっと多様です。いいえ、使い捨てのアプリ用にJQueryをプラグインするだけの子供ではありません。UI要素が非常に複雑な、かなり洗練されたものの構築と保守を支援します。

確かに、デザインスキルが完全に破綻したり、1〜2品質の開発者問題で平凡な開発者を大量に投入している場合、ここで何度か微調整することで大規模な失敗のカスケードを作成する機会がたくさんあります。

TDDがあなたのために何をすべきかについての私の理解は、テストは本当にあなたがより慎重に設計を検討し、要件に集中し続けることを強制することに関するものだということです。結構なことですが、ここでの問題は、インターフェースの設計であるあなたのすべきことを、インターフェースのテスト用に設計されている微妙にしかし根本的に異なるものに破壊することです。私との違いは、ママが意味を推測する必要がないという明確な絵を描くことと、ページ全体を本当に速く緑で塗りつぶすことです。そうすれば、テーブルの上でクレヨンをたたき、「やった！」 」プロセスや設計よりも結果に優先順位をシフトすることで、基本的にガベージコードの継続的な実装を奨励します。これは通常、最初に問題の根本にあったものです。

そしてもちろん、「実際のポイントではない」が、しばしば称賛される単体テスト自体の副次的な利点があり、回帰エラーの検出に役立ちます。TDDの支持者は、これが実際に目標であるのか、それとも単なる気の利いた副作用であるIMOであるのかについて、少し欲張りになりがちです。コード、特にJavaScriptのようなより動的な言語では、依存関係の長いチェーンで考えられるすべてのシナリオを予測することさえできるとは限りません。

JSには自動テストの場所がありますが、別のコードと接触するコードのすべての「ユニット」にユニットテストを添付するよりもはるかに時間を有効に活用することで、作業を複製する、またはそもそも意図した使用法が意味的にあいまいなガーベッジオブジェクト。DRYの原則に従います。再利用/ポータビリティのために、その価値が明らかになったら（1分もかからずに）抽象化します。スティックの原則よりもニンジンに沿って一貫したプロセスと方法を確立します（つまり、間違った方法でやりたいと思うのに適切な方法で物を使うのは簡単すぎます）。fooとbarのすべてのものを愛するために、コードの再利用の手段として、大規模なカスケード継承スキームのアンチパターンに決してふけることはありません。

上記のすべてが、コード内の診断が困難なバグを深刻な方法で減らすのに役立ちました。これは、「不明なファイルのこの架空の行番号にある「オブジェクト」タイプのオブジェクトに問題があります。」（そうですね、IE6に感謝します）TDDは私の仕事の中で、これらのことを奨励しません。それは、ポイントAとBの間にあるものがそれが機能する限り実際には重要ではないプロセスで、100％の結果に焦点を移します。そもそも混乱を招くことなく、読みやすく、持ち運びが容易で、変更しやすいものにするためには、時間の無駄が必要です。

または多分、私は自分が根付いているパラダイムだけを過度に汚しているのかもしれませんが、私の意見では、最初に正しく行うことは、あなたまたはあなたの他のすべての人のためにあなたのお尻を覆うよりもはるかに効果的な時間の使用ですチームは間違っています。そして、物事を実装するだけで設計を検討することを強制するものではありません。設計は、すべてのプログラマーにとっておかしな祭壇でなければなりません。そして、正しいことをするように「強制する」か、自分からあなたを守るものはすべて、ヘビ油のボトル、IMOに予約されているのと同じ疑いで見られるべきです。最新のITおよび一般的な開発におけるスネークオイルは、まだ知らない場合は、液体トンで販売されています。

私の経験では、単体テストは実際に非常に役立ちます。単体テストから始めてそのままでいる場合、つまりテスト駆動開発です。その理由は次のとおりです。

• 単体テストでは、それを行うコードを作成する前に、必要なものについて考え、それを取得したことを確認する方法を強制します。TDDシナリオでは、最初にテストを記述します。そのため、「赤」テストを記述し、次にコードを記述して「緑」を作成するために、作成しようとしているコードが何をする必要があるのか​​、それが成功したことを確認する方法を知る必要がありますそれを渡します。多くの場合、これにより、このテストに合格するために作成しようとしているアルゴリズムについてもう少し考える必要があります。これは、論理エラーと「コーナーケース」を減らすため、常に良いことです。あなたがテストを書いている間は、「どのように考えている可能性があり、これは失敗」や「私は何をしていないより堅牢なアルゴリズムにつながる、ここでのテスト」。

• 単体テストでは、作成しようとしているコードがどのように消費されるかを考える必要があります。TDDを学ぶ前に、依存関係が一方向に機能することを期待するコードを書いた後、まったく異なる方法で働く同僚によって書かれた依存関係が与えられたことが何度もありました。TDDでもこれは可能ですが、記述している単体テストでは、記述しているオブジェクトの使用例であるため、記述しているオブジェクトをどのように使用したいかを考える必要があります。次に、使いやすいようにオブジェクトを記述し、必要に応じて適応できるように願っています（ただし、事前定義されたインターフェイスへのプログラミングは、TDDを必要としないこの問題の全体的な解決策です）。

• 単体テストでは、「テストによるコーディング」が可能です。ReSharperのようなリファクタリングツールは、許可すれば親友になります。これを使用して、テストで使用法を定義するときに、新しい機能のスケルトンを定義できます。

  たとえば、新しいオブジェクトMyClassを作成する必要があるとします。まず、MyClassのインスタンスを作成します。「しかし、MyClassは存在しません！」とReSharperは不平を言う。Alt + Enterキーを押して「それから作成」と言います。そして、あなたにはクラス定義があります。テストコードの次の行では、メソッドMyMethodを呼び出します。「しかし、それは存在しません！」とReSharperは言います。「それから作成」して、別のAlt + Enterで繰り返します。いくつかのキーを押すだけで、新しいコードの「スケルトン」を定義できます。使用法を具体化し続けると、IDEは何かが収まらない場合に通知します。通常、ソリューションはIDEまたはそれに接続するツールが修正方法を知っているほど単純です。

  より極端な例は、「トリプルA」モデルに準拠しています。「アレンジ、アクト、アサート」。すべてを設定し、テストしている実際のロジックを実行してから、ロジックが正しいと断言します。このようにコーディングすると、ソリューションをテストにコーディングすることは非常に自然です。次に、キーを数回押すだけで、そのロジックを抽出し、実稼働コードで使用できる場所に配置してから、テストに小さな変更を加えて、ロジックの新しい場所を指すようにすることができます。この方法で行うと、テストするユニットにアクセスできる必要があるため、コードをモジュール化された再利用しやすい方法で設計する必要があります。

• 単体テストは、考えられるどの手動テストよりもはるかに高速に実行されます。大規模なプロジェクトの場合に非常に迅速に対応できるポイントがあり、手動テストに費やす時間を削減することにより、単体テストの時間オーバーヘッドがそれ自体に対価を払うようになります。書いたばかりのコードを常に実行する必要があります。従来は、大きなプログラムを起動し、UIをナビゲートして動作を変更した状況を設定し、UIまたは生成されたデータの形式で結果を再度検証することにより、手動でこれを行いました。コードがTDDされている場合は、ユニットテストを実行するだけです。優れた単体テストを作成している場合、後者のオプションは前者よりも何倍も高速になります。

• 単体テストは回帰をキャッチします。繰り返しになりますが、TDDを学び、コードの一部に外科的な変更を加えたと思われるものを作成し、その変更が報告された状況で誤った動作を修正したことを確認しました、リリースのためにチェックインしました。同じコードブロックを再利用した偶然の完全に異なるモジュールで、変更が他のコーナーケースを壊したことを見つけるためだけです。TDD化されたプロジェクトでは、これから行う変更を検証するテストを作成し、変更を加え、完全なスイートを実行できます。コードの他のすべての使用法がTDD化され、私の変更が何かを壊した場合、それらのテスト他のことが失敗し、調査することができます。

  開発者が潜在的な変更の影響を受ける可能性のあるすべてのコード行を手動で見つけてテストする必要がある場合、変更の影響を判断するコストによって変更が実行不可能になるため、何も実行されません。少なくとも、複数の場所で使用される可能性のあるものに触れることは決してないので、何も固まらず、したがって簡単に保守されることはありません。代わりに、この1つのケースに対して、非常に似ているが、マイナーチェンジを組み込む独自のソリューションを展開し、SRPおよびおそらくOCPに違反し、コードベースをゆっくりとパッチワークキルトに変えます。

• 単体テストは、一般的に有利な方法でアーキテクチャを形成します。単体テストは、他のロジックから分離して実行されるテストです。ユニットコードをテストできるようにするために、そして、あなたは、あなたが、このような方法でコードを記述する必要がありますすることができますそれを分離します。したがって、疎結合や依存性注入などの適切な設計上の決定は、TDDプロセスから自然に揺り動かされます。テストでは、「副作用」を作成せずにテスト対象の状況の入力を生成したり出力を処理したりする「モック」または「スタブ」を挿入できるように、依存関係を挿入する必要があります。TDDの「最初に使用する」という考え方は、一般に、疎結合の本質である「インターフェイスへのコーディング」につながります。これらの優れた設計原則により、コードベースの大部分を適応させるために変更する必要なく、クラス全体を置き換えるなど、実稼働環境で変更を加えることができます。

• 単体テストは、コードが機能することを証明する代わりに、コードが機能することを示します。一見すると、デメリットだと思うかもしれません。確かに証明はデモンストレーションより優れていますか？理論は素晴らしい。計算理論とアルゴリズム理論は、私たちの仕事の基礎です。しかし、アルゴリズムの正確性の数学的証明は、実装の正確性の証明ではありません。数学的な証明は、アルゴリズムに付着し、そのコードが示すべき正しいこと。単体テストは、実際に記述されたコードが、あなたが思っていたとおりに動作することを示し、したがって、それが正しいことの証拠です。これは一般に、理論的証明よりもずっと価値があります。

さて、ユニットテストには不利な点があります。

• すべてを単体テストすることはできません。ユニットテストでカバーされないLOCの数を最小限に抑えるようにシステムを設計できますが、ユニットテストできないシステムの特定の領域が非常に単純に存在します。他のコードで使用する場合、データアクセスレイヤーはモックできますが、データアクセスレイヤー自体には多くの副作用が含まれており、通常、リポジトリ（DAO）の大部分（ほとんど？）を単体テストすることはできません。同様に、ファイルを使用したり、ネットワーク接続を設定したりするコードには副作用が組み込まれているため、それを行うコードの行を単体テストすることはできません。多くの場合、UI要素は単体テストできません。イベントハンドラーなどの分離コードメソッドをテストしたり、コンストラクターを単体テストしたり、ハンドラーがプラグインされていることを確認したりできます。しかし、ユーザーが特定のグラフィック要素上でマウスをクリックし、ハンドラーが呼び出されるのを監視するためのコード内の代替はありません。適切に単体テストできるものとできないものの間のこれらの境界に到達することは、「サンドボックスの端を削る」と呼ばれます。それ以降は、統合テスト、自動受け入れテスト、および手動テストを使用して動作を検証することに制限されます。

• ユニットテストの多くの利点はTDDなしでは適用されません。コードを書いてから、コードを実行するテストを書くことは完全に可能です。それらはまだ「ユニットテスト」ですが、コードを最初に記述することにより、「テストファースト」開発に固有の多くの利点が失われます。コードは、簡単にテストできる、または実稼働で使用できるように設計されているとは限りません; テストを作成し、あなたが考えていなかったことを考えることに固有の「ダブルチェック」思考プロセスを取得しません。テストによってコーディングすることはありません。コードを作成し、手動でテストして動作することを確認したら、失敗する単体テストをコーディングします。コードとテストのどちらが間違っていますか？主な利点は、リグレッション防止（以前にテストに合格したコードが失敗したときに警告される）と、高速検証と手動テストです。TDD 'の損失

• 単体テストではオーバーヘッドが発生します。簡単に言うと、あなたが書いているコードをテストするためのコードを書いています。これにより、開発プロジェクトの合計LOCが必然的に増加します。はい、テストのLOCは実際のプロジェクトのLOCを超える場合があります。素朴な開発者と非開発者は、この状況を見て、テストは時間の無駄だと言います。

• 単体テストには規律が必要です。コードベースを適切に実行するテストを作成し（コードカバレッジが良好）、定期的に（変更をコミットするたびにスイート全体を実行するように）実行する必要があり、すべてを「グリーン」に保つ必要があります（すべてのテストに合格）。問題が発生した場合は、期待を満たしていないコードを修正するか、テストの期待を更新することで修正する必要があります。テストを変更する場合は、「なぜ」と尋ね、自分自身を非常に注意深く監視する必要があります。現在の動作に合わせて失敗したアサーションを単に変更したり、失敗したテストを単に削除したりするのは信じられないほど魅力的です。ただし、これらのテストは要件に基づいている必要があり、2つが一致しない場合は問題が発生します。これらが完了していない場合、

• 単体テストにはより多くの機器が必要です。上記の規律の必要性、および人間が怠andで満足するという自然な傾向に対する通常の解決策は、ユニットテストを実行し、計算するTeamCity、CruiseControlなどの「Continuous Integration」ソフトウェアパッケージを実行する「ビルドボット」です。コードカバレッジメトリック、および「triple-C」（コーディング規約準拠、la FxCop）などの他のコントロールがあります。ビルドボットのハードウェアは、合理的なパフォーマンスを備えている必要があり（そうでない場合、平均的なチームが行うコードチェックインの速度に追いつかない）、ボットのチェックイン手順を最新に保つ必要があります（単体テストの新しいライブラリが作成され、単体テストを実行するビルドスクリプトを変更して、そのライブラリを検索する必要があります）。これは思ったよりも作業が少なく、しかし、通常、さまざまなビルドプロセスの核心がどのように機能するかを知っている（したがって、スクリプトでそれらを自動化し、上記のスクリプトを維持できる）チームの少なくとも数人の一部の技術的な専門知識が必要です。また、ビルドが「壊れる」ときに注意を払い、新しいものをチェックインする前にビルドが（正しく）壊れる原因を修正するという形での規律も必要です。

• 単体テストでは、コードを理想的でない方法で設計することができます。TDDは通常、コードのモジュール性と再利用性には適していますが、コードの適切なアクセシビリティに有害な場合があります。実稼働ライブラリに配置されたオブジェクトとメンバーは、単体テストで直接使用される場合、プライベートまたは内部にすることはできません。これは、他のコーダーがオブジェクトを見たときに、ライブラリに存在する何かを代わりに使用する必要があるときに使用しようとするときに問題を引き起こす可能性があります。コードレビューはこれに役立ちますが、懸念される場合があります。

• 単体テストでは、一般に「高速アプリケーション開発」コーディングスタイルが禁止されています。単体テストを作成している場合、「高速かつ緩い」コーディングはしていません。それは通常良いことですが、あなたがコントロールの外から課せられた締め切りの下にあるとき、またはあなたが非常に小さなスコープの変更を実装しているとき、利害関係者（またはあなたのボス）はなぜこのすべての残酷なことがただ起こる必要があるのか​​疑問に思っています1行のコードを変更するだけでは、適切な単体テストスイートを作成して維持することは単純に実行不可能になる可能性があります。通常、アジャイルプロセスは、開発者が時間の要件について発言できるようにすることでこれを支援します。セールスマンがしなければならないことは、「はい」と言うだけで、実際には「できない」と言って作業を行わなければならない人々が関与しない限り、コミッションチェックを受けます。しかし、誰もがアジャイルではなく、アジャイルには独自の制限があります。

ユニットテストは、正しく使用すると役立ちます。ロジックにはさまざまな問題があります。

「私が開発しているとき、私は多くの試行錯誤を経験します」とケビンは言いました。

偶然のプログラミングを見てください。コードが何をすべきかを理解し、それがユニットテストを介してそれを行うことを証明する方が良いです。プログラムを実行したときにUIが壊れなかったという理由だけで、コードが機能すると仮定しないでください！

s writing unit tests for ASP.NET web forms something that is done often

人々がウェブフォームをテストする頻度を言う統計データの知識はありません。それはどうでもいい事です。UIのテストは難しく、ユニットテストもUIに結合しないでください。ロジックをレイヤー、テスト可能なクラスライブラリに分離します。バックエンドロジックとは別にUIをテストします。

So, question number 2: Would you guys advise me to start writing unit tests?

はい。それらに慣れると、スピードアップします。メンテナンスは、初期開発段階よりもはるかに時間がかかり、費用がかかります。メンテナンスは、初期テストやバグ修正であっても、単体テストで大幅に支援されます。

実用的なレベルでは、ユニットテストは非常に重要な1つの理由で非常に役立ち ます。一度に1ビットのコードをテストできます。

複雑な手順のシーケンス全体を作成し、最後にデバッグすると、多くのバグを見つける傾向があり、プロセスがさらに進んでいるため、プロセスは一般に難しくなります。Visual Studioでは、クイックテストを生成し、少し変更して、そのテストのみを実行できます。その後、たとえば、そのメソッドを呼び出すメソッドがそれに依存できることがわかります。だから、自信を高めます。

単体テストは、プログラムが正しいことを証明するものではありません！：単体テストでは、機密コードのリグレッションをチェックし、作成した新しいメソッドをテストできます。

単体テストは、フロントエンドをテストすることを意図したものではありません：単体テストは、コードが満たす必要のある条件ではなく、書いている新しいメソッドなどをテストするために作成する小さなプロジェクトと考えてください。

単体テストは共同環境に最適です：たとえば、iOSから呼び出しているように、まったく別のテクノロジーを使用している同僚にメソッドを提供する必要がある場合は、すぐに単体テストを作成して、彼が望む方法a）正しいデータを返すb）彼の仕様に従って実行するc）厄介なボトルネックがない

触れていないように見えることの1つは、さまざまなタイプのコードのテストの複雑さです。

単純な入力と出力を扱う場合、一般に単体テストは簡単です。テスト対象のコードのエッジケースを念頭に置いてテストを選択すれば、正しいことを確信できます。そのようなコードのテストを書かないのはおかしいでしょう。（ライブラリーに入るほとんどのコードがこの基準を満たしていることに注意してください。）

ただし、コードが基礎となる複雑なデータ（通常はデータベースですが、そうである必要はありません）で遊んでいるか、非常に複雑な出力データを生成するため、テストする巨大なモックを構築する必要があります（ターンするルーチンを考えてください）非常に極端な例として、ゲームレベルへのシード値）およびユニットテストはほとんど役に立ちません。通常、テストケースのすべてをカバーすることは夢のようなものであり、バグを見つけた場合、それはほとんどの場合、あなたが考えもしなかったケースであり、とにかくテストを構築できませんでした。

特効薬はありません。特効薬が主張するほど特効薬ではないが、それが役に立たないという意味ではありません。

ASP.NET Webフォームアプリケーションの単体テストを記述することは一般的ではなく、非常に困難です。ただし、プロジェクトでスキップする必要があるという意味ではありません。

ユニットテストはcorner stonesミッションクリティカルなアプリケーションであり、コア機能が期待どおりに機能するという信頼性と安心を提供します。

実際、Webフォーム開発で使用できるASP.NET MVPパターンを使用すると、ユニットテストをはるかに簡単に導入できます。それは関心の分離とを紹介しability to write essential unit testsます。

調べるのに役立つかもしれない参考文献は次のとおりです。

• ASP.NET Webformsアプリケーションのテストの開始（MVPパターン）
• ASP.NET Web Forms MVPを使用したリダイレクトの実行とテスト
• ASP.NETを使用したモデルビュープレゼンター-CodeProject

単体テストの目的は、システム内で何かを壊す恐れを抱かずに、コードを安全に変更（リファクタリング、改善など）できるようにすることです。これは、（疎結合にもかかわらず）コード変更のすべての効果が実際にはわからない大規模なアプリケーションに非常に役立ちます。

はい、ユニットテストが有用であることは私の経験です。

単体テストは、記述したコードの一部を分離し、それらが分離して動作することを確認することです。実際に、この分離には、テスト対象のオブジェクトと通信するための偽または模擬オブジェクトの作成が含まれる場合とそうでない場合があります。オブジェクトのアーキテクチャに大きく依存します。

単体テストにはさまざまな利点があります。

主に、これにより、テストするユニットが、開発者であるユーザーが動作するはずの方法で動作することが保証されます。これは思ったほどではありませんが、オブジェクトが正しく機能しているとは必ずしも言えません。動作するはずだと思うように動作していることだけが、単体テストなしで必要な試行錯誤法よりもはるかに強力なステートメントです。

さらに、開発者であるあなたが動作するはずだと思った方法でユニットが動作し続けることを保証します。ソフトウェアの変更。これは予期しない方法でユニットに影響を与える可能性があります。

もう一つの副作用は、それはあなたがテストユニットがあることを意味していることであるやる孤立して仕事を。これは一般に、具体的なクラスではなくインターフェイスへのプログラミングを開始することを意味し、結合を減らし、結合性を高めます。これは、優れた設計のすべての共通の特徴です。はい：コードのユニットを有効にして単体テストを実行するだけで、コードの設計が自然に改善されます。

しかしながら...

単体テストはテストの終わりではありません。他の種類のテストが依然として必要です。たとえば、ユニットが期待どおりに機能することを示した場合でも、各ユニットは、それと通信するユニットが期待どおりに機能することを示す必要があります。つまり、コンポーネントは互いに正しく統合されていますか？

テストするレイヤーの数が少ない単純なアプリ（メインウィンドウ->サブメニュー）の場合、変更をチェックするために実行するためにコンパイルしても大丈夫です。

テストしているページを取得するのに30秒のナビゲーションが必要な大規模なアプリの場合、これは非常に高価になります。

これに新しい側面（実際にはかなり古いもの）を追加したいと思います。コードが適切に設計されている場合、単体テストはあまり役に立ちません。

ほとんどのプログラマーはプログラム設計を行わないことを知っていますが、私は今でもそうですし、ユニットテストはTDD文化に適合するためにかなり時間がかかる必要性があることを発見しましたが、これまでのところ1-2私のコードの何千行ものテストごとのバグ-私が書いたものだけでなく、公式のテスターも書いたもの。

もうプログラムの設計もしないと思います-現在の人々はあなたにそれをしないように金型に圧力をかけるでしょう-しかし、おそらくユニットテストは設計に比べて非常に低効率の方法であることを覚えておく価値があります。

これはdijsktraianの引数です。ユニットテストは、実行するのに十分に詳細なプログラムに対してのみ実行できます。

コードを実際に記述する前にフローチャート/状態/アクション図、シーケンス図、オブジェクトインベントリ（および最後のAND最小クラス図）を描画すると、トレースするだけで潜在的に脅威となる可能性のあるバグのほとんどを殺すことができます。行と名前の確認。

今日、クラス図は数百、時には数千のクラスを含むコードから生成され、完全に使用できません-15を超える要素を含むものはすべて人間の認識を超えています。

10 + -5クラスの重要性や今何をしているのかを把握し、複数の視点からコードを確認する必要があります。各図は、見ている視点を正確に表し、何千ものバグを殺します。紙の上に。

• 型が満たされているかどうかを動的コードでチェックインする（単にフローチャートに入力/出力型を表示し、それらを鉛筆または異なる色で接続するだけで）
• すべての状態が処理されているかどうかを確認する（条件の完全性を確認する）
• 行をトレースして、すべてが終了することを確認します（すべてのフローチャートは、数学的に理解された
• 特定のコンポーネントが互いに関係ないことを保証する（すべての依存関係を抽出することにより）（セキュリティに良い）
• 依存関係を関連付けに変換することでコードを簡素化する（依存関係はメンバーメソッドが使用するクラスに由来する）
• 名前の確認、一般的なプレフィックスの検索、同義語の消去など

とても簡単です...

また、アプリケーションがユースケースから直接来た場合、...ユースケースが適切に記述されている場合（ACTOR動詞の主題、キャッシュマシンを開くためのメンテナーの要求）...

コードカバレッジの95％以上でコードを作成しました。もちろん、ときどきユニットテストを行います。計算での境界チェックについては、リファクタリングでもユニットテストを使用しないために深刻な回帰（深刻な：24時間で一掃されません）にまだ会っていません。

時々、描画するだけで3〜4日間コードを1行も実行しません。その後、1日で1500〜2000行を入力します。次の日までに、それらはほとんど生産準備ができています。時には単体テストが（カバレッジの80 +％で）書かれ、時には（さらに）テスターはそれを壊そうとするように求められます。

ユニットテストで何かを見つけるのをまだ見ていません。

デザイン思考がTDDの代わりになることを望みます...しかし、TDDは非常に簡単で、まるでハンマーで行くようなものです...