これが状況です -- 私の上司からの引用: "[...] 私たちはプログラミングに集中する必要があります。 [...] 結局のところ、私は良いソフトウェアを書きたいと思っています。 ." これは、気が遠くなるようなバグのリストが 3 か月間続き、最近、Selenium フレームワークを使用して Web テストを作成するプログラマーではない人を指名した後に言われました。
私の上司は単体テストを非常に恥ずかしがり屋です (開発者の作業が遅くなると、コストのメリットがわかりません)。Web テストとプログラム テスト全般について、どのような意見がありますか? それらは（または）プログラマーによって書かれるべきですか、それとも重要ですか？私の考えでは、良いソフトウェアを書くことの一部はテストを書くことですか? 彼は Microsoft の象牙の塔のような人なので、設計によるテストを支持して Microsoft によって出されたリソース (または一般的には優れた記事) は役に立ちます。
これが私がしたことです。
とにかくテストを書きました。
テストを書いた後、コードを書きました。
コードは堅牢で、(ほとんど) バグがありませんでした (私の能力の限界まで)。
私はTDDをやっていると誰にも言いませんでした。彼らが尋ねない限り。
実際、TDD は、何かを設計し、コーディングし、それが機能することを期待して試行錯誤するよりも高速であることがわかりました。
いくつかのものには、追加のステップ 0 が含まれます。つまり、物事がどのように機能するかを確認するための「テクノロジー スパイク」です。これに続いて、まだ作成されていない実際のソフトウェアを実行するためのテスト開発が行われます。
設計の開始に関しては、予定より少し遅れています。私の設計は「その設計の設計とテストの作成」ですが、他の人々の設計は「いくつかの巧妙なアイデアでスクラッチしますが、実際の証拠はありません」です。紙の上で上手にデザインできる人もいます。私はできません。しかし、私はテストを設計することができます。
コードを完成させることに関しては、私は一般的にかなり先を行っています。それ以来、コーディングが完了すると、すべてのテストに合格します。
Code Complete は、Microsoft Collection の一部である書籍です。ピアレビューを提唱し、ユニットテストをコンセプトとしてブラッシングするためのアドバイスが含まれています。単体テストについて詳しく説明することはしませんが、彼をそのアイデアに惹きつけ、そこからさらにトピックを探ることができるかもしれません。
最終的には、テストの自動化に直接関与するプログラマーが必要です...つまり、それは定義によるものです。
単体テストは、それが書かれたサブシステムに最も精通している人々によって最も効果的に書かれます。他の誰かが単体テストを書くために選ばれた場合、彼らは立ち上げるのに時間がかかり、文書化されていないかコードで明確にされていない意図を見逃す可能性がありますカバレッジが悪化する可能性があります。反対に、サブシステムの所有者は、特定の欠陥に気付かないこともあります (しかし、これがピア コード レビューの目的です!)
これ以降は、倫理に関する無駄な議論にすぎませんが、考慮することは重要です。
経営陣がばかげた決定を下したときに、ビルドに「こっそりと入り込む」ことを好む人もいます。これは私を不安にさせるだけでなく、それらのプログラマーに対して一種の警戒心を抱かせます。私は動機を理解しています。私たちは皆そこにいたと思いますが、最終的には、策略に参加するのではなく、教育する必要があります.
マネジメントはスケジューリングにおいて重要な役割を果たし、正確な見積もりと行われている作業の一般的な理解の両方をあなたに依存しています。敷物の下で余分な作業を一掃するために見積もりをパディングする場合、それは本当に良いことですか? 単純な嘘が、あなたのキャリアアップを支援することに直接関与している人々を欺く手の込んだデマになります。
正当な仕事のプロセスと見積もりの問題だったものが、今では厄介な倫理問題になっています。
理由、論理、および Microsoft に対する彼の愛に訴えることを通じて、あなたの視点を理解するようマネージャーを説得するという計画的なアプローチを実行することを強くお勧めします。;)
長い目で見れば、プログラミング プロセスに関する意思決定で経営陣と常に争っている場合 (実際には意思決定を行うのは彼らの仕事ではありません)、その履歴書を磨き上げて、より良い仕事を見つけるのがおそらく最善でしょう。
プログラマーの仕事の一部は、専門知識の少ない関係者を教育することです。上司にそのことを説明することで、この件に関して彼が持っている知的障壁の一部を打破し、その問題に関するあなたのアドバイスを受け入れるように彼を和らげるのに役立つかもしれません.
私は、何かが「完了」するためには、少なくとも 2 人によって検証される必要があるという世界に行きます。チームの全員が、ソフトウェアの品質は全員の仕事であると信じている場合、チームにソフトウェア テスターが常に必要なわけではありません。
非常に効率的にしたい場合は、コードを書いている開発者がテストを書き、誰かが本番コードでそれらをレビューする必要があります。非常に効果的になりたい場合は、誰かとペアになり、「ペアのtdd」でコードを記述している間にテストを記述します。
バグのコストは発見が遅れるほど指数関数的に増加することをマネージャーに思い出させてください。
あなたの上司がどこから来たのか理解しています。結局のところ、プログラマーは単に「機能する」コードを量産できる必要があります。ただし、単体テスト、社内での統合テスト、顧客へのインストール後など、何があってもテストは行われます。ただし、これらの各段階でのエラーには、さまざまなコストと結果があります...
優れたテスト スイートを作成するには、かなりの労力が必要です。これには予想以上に時間がかかります。
この点で、あなたの上司は正しいです。
ただし、製品の拡張 (機能の追加) または Web サイトの拡張 (ページと JavaScript コードの追加) を計画している場合は、後でスイートを作成する必要があります。
VS2005 以降、単体テストが .Net フレームワークに組み込まれていることを指摘できます。
すべてのテストが同じように作成されているわけではありません。いくつか見てみましょう。
現在、QA は通常、追加のシナリオを考え出します。これは良いことですが、自動化されたテストに共同で組み込むことができれば最高です。
1 つの本当の問題は、現在のチーム スキルです。単体テストは、コードが結合されているほど難しくなります。これは通常、単体テストのない既存のコードでは最悪ですが、疎結合/高結合のコードを設計する方法をよく知らない開発者にとっては、最初は先に進むことが難しくなります。結束コード。実行する必要がありますが、費用はどこか (チーム メンバーまたは会社) にかかるため、注意してください。
仕様の解釈が異なる可能性があるため、他の人にコードをテストさせるのは良い考えだとよく耳にします。ただし、独自のコードのテストを作成する利点は、どこに欠陥があるかを把握できることです。
効率的なアプローチは、両方の混合である可能性があります: プログラマーが独自の単体テストを作成し、コーナー ケースに焦点を当て、他の誰かが機能テストを行い、より高いレベルの仕様に焦点を当てます。