上級開発者は単体テストを免除されるべきですか?それとも、彼らはそれらを実装するために不足者を使用することを許可されるべきですか?ユニットテスト技術を使用してそれらを採用することに慣れていない人々をやる気にさせる最良の方法は何ですか?
13 に答える
TDDの純粋主義者の観点(つまり、実装前に単体テストを作成する必要があると考える)の観点から、上級開発者は、不足しているものよりも多くの単体テストを作成する必要があると主張します。
その理由は、単体テストが最初に来るので、それらを書くにはコードベースの深い知識が必要だからです。貧しい人々にそれらを書かせれば、あなたは本質的にあなたのドメインについてほとんど知らない人々にあなたのコードベースの構造を指示させることになります。それは私には悪い考えのように聞こえます。
不足している人に他の誰かのためにユニットテストを行わせることは、そもそもユニットテストを行うことのポイントを破壊していると思います。コードを書くプログラマーは、コードがどのように壊れるべきか、そしてその予想される振る舞いが何であるかを知っている必要があります。他の誰かが元のプログラマーをその責任から解放しないという理由だけで。
(ジェンダーニュートラルのためにぎこちない言い回し。)
テストを書いている人=システムがどのように機能するかを定義する=「ボス」
テストを実施する人々は、いわゆる「ラッキー」です
新しいトリックが好きではない老犬の場合のように聞こえます。そして、言われているように、それらを変更するのは難しいです... TFD(テストファースト開発)は、一度始めたらとても楽しいです。おそらく、チーム全体が参加するTDDまたはTFDに関する社内の1日ワークショップがあります。
上級開発者は単体テストを免除されるべきですか
絶対違う。その場合、彼らは上級開発者であってはなりません。上級開発者は道を示すリーダーでなければなりません。貧しい人々がそれを行うという考えはばかげているように思われます。
これらの状況を処理するための1つの可能な方法は、上級開発者が単体テストの大部分を作成できることだと思います。つまり、彼らはプログラムの動作方法を定義および設計しているということです。その後、貧しい人々はテストに一致するコードを記述し、彼らがテストに参加している間に年配の男性の設計哲学を学ぶことができます。
パート I (上級開発者と単体テスト)
TDD またはテスト駆動設計について考えるとき、単体テストは、システムの進化的な設計を追い出し、できれば継続的な改善を保証する目的に役立ちます。
テストを書くことで、コードが形成されたり、すでに下された決定の問題が強調されたりします。うまくいけば、リファクタリング プロセスが設計の品質を向上させます。
私の経験では、上級開発者は通常、経験と能力が最も高い人物です。つまり、これらのリファクタリングの機会を見つけやすい位置にいるべきです。(コードの匂いを検知)
頭のてっぺんから、あなたのためにテストを書いている他の誰かが受け入れられる可能性がある状況が 3 つあります。
- 受け入れテスト/顧客テスト/エンド ツー エンド テスト。何と呼んでも構いませんが、データ入力ポイント (Web サービス、Web ページ、アプリケーション画面入力) から開始し、システムのスタック全体を横断する (データベース、別のサービスへの呼び出し、入力結果画面に戻るなど)。これは、テストによって実行される個々のユニットの詳細を実装していない人によって書かれる可能性があります。
ペアプログラミング (ピンポンパターン) -
A は新しいテストを作成し、それが失敗することを確認します。
B は、テストに合格するために必要なコードを実装します。
B は次のテストを書きます。
Aはそれを実装します。バグ修正テスト - バグが見つかった場合、多くの場合、欠陥を明らかにする失敗したテストを作成することをお勧めします。このテストが実施されると、誰かがテストに合格するコードを実装する可能性は十分にあります。欠陥のために失敗するテストを書くという行為は、多くの場合、修正がどのように生成されるかについていくつかの洞察を与えるため、これはそれほど良い考えではないと思います。
要するに、あなたの最初の質問に対する私の答えは、上級開発者が単体テストの作成を免除されるべきではないということです。
パート II (人々にテストを書く動機を与える)
これは私が過去に問題を抱えていたことです。現在、適切な頻度で TDD を実行しようとしていますが、テストを作成することに実際の利点があることがわかるまでに数か月かかりました。
TDD と単体テストの利点を他の人に見せようとするのは非常に難しいと思います。TDD/単体テストが自分のコードの微妙な点を浮き彫りにし、他の方法では見逃していたかもしれない、または短時間でバグを修正するのに役立った、その「ああ」という瞬間を、その人が自分自身で経験したときだけ、利点を参照してください。それらをその時点に到達させるのは非常に難しい場合があります。
個人的には、前述のピンポン パターンでペア プログラミングを行い、経験豊富な TDD 担当者と協力して、機能の重要な部分を解決するために書いたコードが洗練されたソリューションと呼ばれるものに進化するのを見て、そこにたどり着きました。その後、QA を通過し、欠陥が発生することなくライブ環境に移行する作業が続きます。
要するに、単体テストを書くことから得られる利点をすでに確信している経験豊富なプログラマーとペアを組むことは、誰かが単体テストを書く意欲を高めるのに役立つと思います。
絶対違う; 少なくとも、自分で開発したコードのテストを作成する方がはるかに簡単だからです。ただし、年功序列に関係なく、すべての開発者がすべてのコードを単体テストすることが重要です。コードがテスト可能でなければならないことを知って開発した場合、彼らの労働の成果ははるかに大きくなります。
開発者を単体テストに動機付ける必要がある場合は、長期的に節約できる利点と時間を押してください。彼らが自分たちのコードの単体テストを書く習慣を身につければ、当然のことながらすぐにそれを始めます。
あなたが上級開発者である場合、それは、ユニットテストがより良いソフトウェアを作成するのに役立つ優れた開発プラクティスであることを十分に経験しているためです。
上級開発者が独自のテストを行っていない場合、彼らは上級開発者ではありません。
テストする意欲の欠如は、ほとんどの場合、怠惰または不適切(またはその両方)の兆候であり、どちらも上級開発者に見られるべき特性ではありません。
上級開発者が他の誰かに単体テストを書いてもらうことが適切であると私が考えることができる唯一のシナリオは、後輩の新入社員が物事をスピードアップしている場合です。コードを書いているときに足を濡らすのは良い仕事かもしれません。
単体テストの最大の利点の 1 つは、作業の成果を示す即時フィードバックです。テストの実装を外部委託すると、設計が機能するかどうかについてのフィードバックは得られません。そして、悪い設計に苦しんでいる人には、それを修正する手段がありません。
私は TDD の信奉者ではありませんが、単体テストやその他のテストには多くの価値があると考えており、コードを作成するときに頻繁に実行しています。
要点は、コードを書いた人以外には、そのコードが何をするべきかを本当に知っている人は誰もいないということです。
それを念頭に置いて、テストを書く「怠け者」から多くの価値を得ることはありません。
- 彼らはすべての微妙なコーナーケースを深く理解しているわけではありません
- コードには何も投資していないため、彼らはコードを気にしません。
- 彼らはばかみたいに扱われているように感じるでしょう。
彼らがばかであっても、誰もそのように扱われるのが好きではありません. スタッフを辞めさせたい場合、これは彼らを励ます良い方法です。
単体テストの作成を免除されるべきではありません。すべての開発者がそれらを記述できる必要があり、単体テストもコード レビュー プロセスの一環としてレビューする必要があります。単体テストの複雑さは、通常、開発者のスキルの関数になります。より複雑なコードはより上級の開発者に渡されます。そのため、より複雑で多数の単体テストも彼らに渡されます。
適応できない開発者が 1 人以上いる場合は、1 対 1 の支援を提供し、開発者がコツをつかみ始めるまで単体テストをペアリングする必要があります。コードを書ける人が単体テストを作成できないほど技術的に複雑なことはありません。そうであると思われる場合、それはおそらく、その人のスキルセットに関するより大きな問題の前兆です。
個人的には、テスターがプロジェクトの一部である単体テストを少なくとも理解できるようになることも役立つと思います。開発者とテスターの間のコラボレーションは、欠陥を正しく診断して修正する上で非常に重要です。彼らがそれらを書く必要があるとは思いませんが、開発者と一緒に座って、テストが失敗する理由/方法の概念を検討できるはずです。
はい、そうですが、見つかったバグの修正を上級者に任せることが下僕に許可されている場合に限ります。それは彼に教えます。