「コーディングするだけなので」単体テストを使用したくない同僚

同僚は単体テストを使用することを嫌がり、代わりに簡単なテストを選択してユーザーに渡し、すべてがうまくいけばライブで公開されます。言うまでもなく、いくつかのバグは解決されます。

私はユニットテストの使用について考えるべきだと言いましたが、彼女はより多くのコードを書かなければならないことに気づいたら、それに対してすべて反対しました。これにより、特に彼女のコードがスパゲッティであり、機会があればリファクタリングしようとするので、何かを変更し、出力が同じであるかどうかを確認することができません。

それでは、私にとって最善の方法は何ですか？

彼女は単体テストの利点を認識していないため、変更する必要があります。

• 彼女の意識。

あなただけではなく、彼女の仕事を改善することを彼女に証明する必要があります。それは難しいでしょう。彼女はおそらく、変化を恐れているなら見つけることができるあらゆる否定的な側面に集中しようとするでしょう。

すべての利点について彼女と話し合い、彼女のすべての反論に耳を傾けることができます。彼女が話し終わるまで待ってから、自分で話し始めます。

準備を整えるには、P.SEまたはGoogleで管理や開発者が単体テストについて心配しているすべてのことを確認し、同僚との話し合いで使用する回答をまとめる必要があります。

彼女に耳を傾け、それが彼女の仕事を改善するという証拠を提供するだけで、あなたを大いに助けます。あなたは彼女の意見に懸念があることを証明し、状況を分析し、最終的に彼女の心を変えるために必要なすべてのデータを彼女に提供します。

単体テストを書く（彼女に言わないで）

事が壊れるまで待って、2日間手動テストをさせてから、ユニットテストを引き出して3秒でバグを見つけます。

カバーを取る...

それ以外の場合は手動タスクを自動化することは、プログラマーにとって魅力的です。

そのため、彼女は「より多くのコードを書く」のではなく、手作業を少なくしています。

（テストの1つ）自動テストのポイントは、再現性です。手作業で簡単なテストを行うと、単体テストと同じように書くよりも速く実行できます（少なくとも単体テストの初心者の場合-単体テストの経験がある人なら誰でも、テストを非常に高速で実行できます）。

しかし、明日、または来週、コードに小さな（または大きな...）変更が加えられるとどうなるでしょうか？何も壊れていないことを確認するために、あなたの同僚は、変更のたびに同じ手動テストを何度も喜んで繰り返しますか？または、彼女は「コードと祈り」を好むでしょうか？

コードが変更されるほど、ユニットテストは初期投資を回収します。テストが実際にバグをキャッチしなくても、ポジティブな面を得るのに時間がかかりません。しかし、彼らも定期的にそれを行います-この時点で、彼らは非常に貴重になります。そして、誰かがその安全性の感覚と、成功した単体テストの実行が与えるコードへの自信を経験すると、通常、後戻りすることはできません。

彼女が新しい分野に進出することを確信しているが、恐れている場合は、ペアプログラミングセッションを提供して、最初のユニットテストを一緒に書きます。テストするのは難しくないが、テストする価値があるほど複雑なクラスを選択してください。

ただし、彼女が納得していない場合は、難しい事実を収集する必要があります。そのような事実は

• あなたと彼女が書いたコードの欠陥率
• 彼女のコードに対して単体テストのセットを書き、見つかったバグを文書化します。

そのようなデータをいくつか収集し、その結果を丁寧に示します。それでも彼女を説得するには不十分な場合は、問題について話し合い、収集した証拠を経営陣と共有する必要があるかもしれません。それは最後の手段に過ぎないはずですが、他の方法がない場合もあります。

彼女のコードの最悪の部分について基本的なテストカバレッジを作成し、それらのテストに基づいてそれをファクタリングし、連続ビルドでのユニットテストが生産性を向上させるという管理を主張します。変更は、1人の開発者が福音を伝えるよりも雇用主が義務付けた方が簡単です。

これを適切に表現する方法がわかりませんが、「チャンスが訪れたとき」にコードをリファクタリングしている場合...まあ、彼女はおそらく「自分のビジネス」に自分自身を巻き込むためのちょっとした潅水だと思うでしょう、したがって、オープンな心であなたに耳を傾ける可能性は低くなります。私の経験では、人々は自分がやったことに執着するようになります。

悪魔の擁護者を演じるために：彼女はポイントを持っています。私は通常それを次のように置きます：

自動テストは、より多くのコードで多くのコードの問題を解決します。

根拠：

• 障害率とオブジェクト指向メトリックの相関関係に関する研究、ヘッドライン結果： 「[クラスの]サイズを制御した後、我々が研究したメトリックはいずれも障害傾向に関連していませんでした」。（この研究ではクラスのサイズについて説明しています。この効果はコードベースのサイズにまで及ぶのでしょうか？おそらく、私の意見では）
• 経験的に、大規模プロジェクトはゆっくりと進む傾向があります。「新しいプロジェクトで一晩で5,000行」と「大規模プロジェクトで1日あたり10行」。それは、コードベースのサイズとともに増加する変化に対する「抵抗」を示していますか？
• 私たちは常に「最高の言語はない、それは問題次第だ」と宣言します。重要な要件の1つは、選択した言語で問題のエンティティと操作を簡単にモデリングすることです。それはあなたの問題を表現するのがより複雑な言語を選択することは悪いことを示唆していませんか？それは再びコードベースの最終サイズと相関していませんか？

今、それに対して簡単に発砲するいくつかの議論があります。私が考えることができるものをアドレスさせてください：

• サイズと単純さ：もちろん、コードを短くしたり悪化させたりすることは可能です。ただし、これは、簡潔さと対単純さの比率が異なるコードベースを比較する場合の問題にすぎません。議論のために、この要因を何らかの形で制御できると仮定できます。

• 単体テストは依存関係を減らすように圧力をかけますが、依存関係を減らすことでコードサイズの問題を緩和できるという経験に同意します（同じサイズの2つのコードベースの場合、相互依存関係が多い方が悪いという意味です）。ただし、量産コードユニット間の依存関係は削減されますが、テストとユニット自体の間にカップリングが導入されます。

TL; DR：単体テストが悪いとは言いません。私は尋ねます：コードの量に相関するテストが傷つく損益分岐点はありますか？

あなたは難しい立場にいると思います。私は、人々が単体テスト、またはさらに悪いことに、メンテナンス不能な恐ろしい単体テストを書かないチームにいました。しかし、誰もがユニットテストが良いという事実を知っていました。

したがって、チームの単体テストスイートを高品質にすることは、長い間困難な道のりでした。常に物事を改善できる場所に目を配り、アイデアを伝え、経験を共有します。

一方、あなたはその利益を実現さえしていない開発者を持っています。また、スパゲッティコードもコーディングします。この特定のケースで最も重要な理由の1つは、適切な単体テストを記述すると疎結合設計が強制されるという事実だと思います。そのため、彼女にテストを書かせることで、長期的には「実際の」コードが改善されることを願っています。

しかし、最終的にはチームの決定だと思います（チームに何人いるのかわかりませんか？）。よくカバーされた単体テストスイートが必要であるというコンセンサスにチームが到達できる場合、全員が順応し、経験を共有し、チームを一緒に成長させなければなりません。

ただし、ユニットテストを作成する必要があるというコンセンサスに達しない場合は、別の開発チームを見つけて作業することをお勧めします;）

彼女はボスですか？

もしそうなら...あなたは基本的に「1オンスの予防は1ポンドの治療に値する」という線に沿った利益を彼女に納得させることができない限り、あなたはちょっと立ち往生している。バグが発生します。TDDは、一貫性のある出力を構築することにより、その軽減に役立ちます。

彼女は上司ではありませんか？

あなたが働いているコーディング標準は何ですか？なぜ彼女はスパゲッティコードを吐き出すことができますか？「TDDにもう少し時間をかけると、バグにあまり時間をかけない」というビジネスケースを上司に提示します。ビジネスケースで変更を実施できる人を説得します。

TDDが時間と$$ MONEY $$を節約できたケースを文書化します。

このバグはそれ自体を提示しました。ライブに行く前にキャッチされていたでしょう。2時間の予防策を講じることで、10時間の治療が可能になります。こことこことここで起こった。会社を30人時間節約する10時間の作業。これだけのお金です。

これにより、何かを変更することができます。

どうして？

彼らは問題を作成しました。彼らはそれを解決する必要があります。

どのマネージャーがこれを許可していますか？他の誰かのバグのあるコードがなぜあなたの問題なのですか？

これを実現させている同僚とマネージャーがいます。そして、彼らの混乱を一掃することにより、あなたは喜んで積極的な参加者になります。

質の悪い痛みを感じなければ、何も変わりません。

彼女は非常に正しいです、ユニットテストは「より多くのコード」です。

ただし、プログラムがどのように機能するかを（何度も）確認するために記述する必要があるのは、より多くのコードです。無駄な時間ではありません。コアコンポーネントと同じくらいシステムの一部です。

彼女に挑戦：

1. コードに慣れていない人が何かを変更するとどうなりますか。
2. 経験の浅い人が何かを変えるとどうなりますか。
3. システムの維持コストは、作成にかかる時間では測定されません。長期的な提案です。総所有コストについて考えてください。
4. 彼女の見積もり（コーディングを開始する前に必要だった場合）には、単体テストを作成する要件を含める必要があります。ビジネスの人々は、単体テストを直接必要とする要件を作成しませんが、暗黙の品質要件を持ち、将来の変更がバグに埋もれたり、同じプログラマーがソースを変更したりすることを要求しません。

現在生産コードを実行しているものと言えば、TDDではなく単体テストが続きます。これは、現在の場所には適していないようです（一部のプロジェクトでTDDを実行しましたが、銀の弾丸ではなくol 'バッグ）...

売れ行きが悪い場合があります。私はまだ単体テストで同僚を売ることができませんでした。ユニットテストコードでは、運用コードよりも多くのエラーが発生する傾向があることを知っています。そのため、単体テストコードの修正に多くの時間を費やさなければならないのは少しイライラします。しかし、コードが変更されたときは、素晴らしい保険になります。エッジの状態を自動的にテストする素晴らしい方法。

自分で単体テストを作成して、単体テストがどれだけ役立つかを見せてください。

セントフランシスがかつて言ったように、「常に説教してください。必要なときは言葉を使ってください。」

あなたのコードが単体テストを使用していること、そして単体テストでバグをより迅速に解決できることを彼女が見た場合、それは彼女の心を変えるかもしれません。しかし、そうではないかもしれません。

結果に関係なく、彼女はあなたがあなたにしたくないことを彼女に押し付けているとは思わない。それはあなたが変えなければならないものであり、あなたは例によってリードしていないという認識です。