チームの新人でありながら、既存の統合と単体テストの品質について何ができますか？

私がキャリアで出くわした繰り返しのテーマは、チームに到着する新しい開発者であること、そして既存のユニットと統合テストスイートに対する固有の不信をすぐに持つことです。

面接中に、経営陣から「ユニットテストを強力にサポートしている」ことと、それを公然と奨励していることが伝えられます。彼らはそうしますが、テスト自体についてのすべては単に間違っています。100％の統合テストカバレッジがあり、10％未満の反復可能な単体テストカバレッジがある場合、100％のカバレッジを主張しているという事実と同様です。私が見つけた他のいくつかの問題：

1. 単体テストと統合テストの間に明確な兆候はありません。単体テストと統合テストは、同じクラスに混在しています。

2. 特定の環境のデータベース上の非常に特定の動的データに対する未宣言の明示的な依存関係がある統合テスト。

3. 非トランザクション統合テスト。基本的には、後からクリーンアップするかどうかわからないテストであり、テストを再現可能にするために手動のデータベース「スクラビング」が必要になる場合があります。

4. モッキングは一切行われません。アプリケーションコードでは、モッキングを可能にするためだけに大幅な見直しが必要です。つまり、テストを考慮せずに設計します。

5. テスト名をすばやく確認して、実行中のテストを大まかに判断するための明確な命名規則はありません。

これは、すべてのテストが役に立たないか悪いというわけではなく、かなりの数のテストが非常に良く、維持する価値があると言っているわけではありませんが、金のためにパンするような気がします。ブラックボックステストケースのデータベースを台無しにするのが怖かったからといって、意図的にテストを実行することは避けました。

これは本質的に、私が個人的に何らかの方法で書いたりレビューしたりしていないユニットおよび統合テストの固有の不信感を与えました。あるレベルでは、テストスイートの品質を信頼していない場合、チームやプロジェクトにはまったく価値がありません。

この状況に陥ったとき、あなたはどうしますか？攻撃の最善の計画は、このようなものに取り組むことだと思いますか？

すべてのテストをリリース間で途方もない努力でリファクタリングする必要がありますか？このレガシープロジェクトが1日の強固な単体テストの対象となる可能性があるという考えを捨てる必要がありますか？

まず、他のポスターがすでに書いているように、ユニット/統合テストが理解され（技術的な方法ではなく、それが行われる理由が理解されていることを意味します）、経営者によってプッシュされることを幸せにすべきです。

すべてを実行する前に、問題を経営陣にさらす必要があります。何をすべきか、そして、あなたが世界一のプログラマーだとは思わないように、非常に外交的に（あなたがそうであっても！:-) たぶん彼らは、アプリケーションが完全に新しいものに置き換えられることを教えてくれます。そして、彼らはそれが素晴らしいことを認識し、各リリースの前にテスト段階をスピードアップするかもしれません。そして、チームメイトと外交してください、それが現状のままである理由は百万あるかもしれませんし、犯人を探す理由はありません。

より良いアイデアは、彼らが努力に参加できるように彼らと話をしようとすることです、そしてあなたは賢い尻として現れる機会が少なくなります、それは「私」よりも「私たち」です。

今、あなたがしたいことに優先順位を置きます。タスクを優先し、常に最優先事項が常に現在のプロジェクトの割り当てであることを知って...テストの問題に関しては、次の3つの段階で行います。

1. 単体テストと統合テストの違いを作る方法は？次の解決策が適用される可能性があり、排他的ではありません。

   • テストケースメソッドの名前をリファクタリングします（正しい動作はテストケースにテスト対象のクラスと同じ名前を持たせることであるため、クラスではありません）
   • 2つの注釈を作成します。1つは「UnitTest」、もう1つは「IntegrationTest」という名前です。これらの注釈は、クラスおよびメソッドで使用できます。クラス全体が単体テストまたは統合テストのいずれかで構成されている場合、適切な注釈でクラスをマークできます。そうでない場合は、各メソッドに正しい注釈を付けることができます。また、これらの注釈は、テストを開始する前にフィクスチャを動的に注入するのに役立ちます（フェーズ3）

2. 各統合テストについて、各テストの開始時にデータベース内にあると予想される「データセット」と、その終了時に削除する必要のあるものをリストします（例：表X、「id」のレコードが必要です） 「1」に設定し、「名前」を「foo」に設定するなど）。コード自体がそれぞれ永続層からオブジェクトを追加/削除する可能性があるため、削除するものは最初に持っているものよりも大きい/小さい場合があります。これらのテストケースのいくつかは、同じデータセットまたは同じデータセットの一部を必要とすることにすぐに気付くでしょう。

3. 最初の2つのフェーズは、他のフェーズと比べて比較的迅速に実行できます。データセットができたので、必要なテストケースごとにデータセットフィクスチャを作成します。しかし、それには時間がかかります...だから、あなたはそれをすることができ、それがあなたにどれくらいの時間を費やすかを見て、あなたがすべてをするのにどれだけ時間が必要かを見積もることができます。また、そのテストを使用して、仲間の同僚に自分が何をしたか、そしてテストを実行するために特定の州の法律にデータベースを必要としないとき、なぜ人生がこれほど簡単かを示すことができます。

フェーズ1、2、および3は、同僚/管理者にその方法をすぐに見せたい場合、単一のテストクラスで行うことができます。PéterTörökが書いたように、これはチームメイトに「良い方法」をすぐに見せて、悪いコードの生成を止めるためにも役立ちます。ただし、テストデータセット全体を特定するフェーズ2の残りは、1つの大きなステップで行うのが最適だと思います。

すべての背後にあるAPI /テクノロジーについては、あなたは主題を知っているようです。

それが少し助けてくれることを願っています。

注：私の提案では、アノテーションとAOPが可能なJava / C＃のいずれかでコーディングすることを想定しています。これは他の言語でも可能であると確信していますが、私が知らないことについては書きません。

すべてのテストを一緒に修正することはできません。私はあなたが単語に焦点を当てるべきだと思うの改善対オーバーホール。開発者ではなく経営陣もオーバーホールに同意しませんが、プロジェクトに悪影響を与えずに物事を改善する方法があることを示すと、彼らは耳を傾ける可能性が高くなります。

まず、品質テストの範囲がない限り、既存のコードを「修正」またはリファクタリングすることはできないため、まずテストインフラストラクチャの修正に焦点を当てます。

改善が必要なもののリストを作成し、それらに優先順位を付けようとします。テストを独立して単独で実行できる（相互に影響しないようにする）こと、および単体テストと統合テストの分離が最初に取り組むべき作業の一部だと思います。自分や他の人が正しいことを簡単に行えるようにする必要があります。

アプリケーションコードに関する限り...単体テストを改善するために、アプリケーションアーキテクチャの完全なオーバーホールを行うことはできません。代わりに、新しいコードを入力するときに、ユニットテストを簡単にする原則（依存性注入など）を適用してください。これは変更の大きさではないと思うかもしれませんが、開発者が利益を享受した場合、開発者がどれほど速く定着するかは驚くべきことです。良い方向に変化を起こし始める人が必要なだけです。

チームと話をして、彼らに賛同を得てもらいましょう。あなたができる最も重要なことの1つは、 " ボーイスカウトルール " に従い、あなたが見つけたより良い形でクラスやテストを残すために小さな改善をすることです。チーム全体がこのルールを適用すると、事態はより速く改善されます。

しばらくすると、良い原則と悪い形のアプリケーションの領域に従う多くのコードができます。この時点で、良いもののベースラインが得られ、チームは、古いレガシーのものに対してより大きなリファクタリングを行うことが有益か、それともそのまま生きることができるかを決定できます。

既にかなりの数のユニット/統合テストが行​​われているプロジェクトにたどり着くのは珍しい贈り物だと認めなければなりません。これまでの人生で幸運は一度もありませんでした。すべてが正常に機能していない場合でも、すでに多大な労力が費やされています。チームと経営陣が常にベストプラクティスに従っていない場合でも、彼らはすでに原因にコミットしているので、ユニットテストを書く価値がある理由について議論する時間を費やす必要はありません。

ただし、テストを記述するときに、実際にいくつかの改善を行うことができます。しかし、チームメイトと問題を議論するときは、トーンに注意する必要があります。「テスト自体に関するすべてが単純に間違っている」と述べることから始めると、チームの残りの部分をすぐに疎外してしまう可能性があります。代わりに、現在の情勢を改善する方法に焦点を当てる必要があります。これは、繰り返しますが、これまでの私の経験によると、平均よりもはるかに優れています。

IMO の最初の目標は、チームがより悪いテストを作成するのを止めることです。そのため、チームメイトに特定の各改善の利点を示すことから始めます。外部の依存関係のカット、各テスト後の元の状態の復元、単体テストと統合テストの分離など、特定の手法の有用性がわかると、それらの適用が開始されます。これにより、長期的にはテストベースの全体的な品質がゆっくりと確実に向上します（現在、1000件の不良テストケースがあり、来年までにチームが1000の良好なテストを作成した場合、不良テストの比率を下げます100％から50％まで）。それが確保されたら、ケースバイケースで既存のテストのリファクタリングを決定できます。繰り返しますが、小さな改善は、時間の経過とともに大きな変化をもたらします。

サイドノートとして、あなたの投稿のトーンから、私はあなたが私もいる場所にいるかもしれないと感じています：他人によって行われた仕事を信頼していない、あなたの仕事があなたに任せられないのを恐れて誰にもタスクを委任できない独自の品質基準。私の経験では、これは良い場所ではありません。長い目で見れば、個人的な葛藤や燃え尽きにつながりやすいからです。すべてを単独で行うことはできません。チームの他のメンバーと協力する必要があります。一緒にしか成功できません。

テストの独立に向けて働きます。テストXがテストYが失敗するようにテストデータベースを変更する場合、テストYを変更します。この小さなシナリオで注目すべきことは、Xがデータベースを台無しにすることではなく、Yが不適切な依存関係を持つことです。これらの依存関係を削除し（データベースをスタブする、テストを再構築する、またはデータベースをYが合格する状態に初期化する）、これでもう1つの独立した作業テストができました。それは進歩です（データベースを混乱させないようにXを「修正」することは間違いないでしょう）。

彼らが作成した混乱にもかかわらず、あなたが一緒に働いている人々について、できる限り忍耐強く敬意を払ってください。彼らはおそらく正しいことをしようとしています。それを念頭に置いて、彼らがそれをするのを助けてください。

チームに初めて参加することの良いところは、物事に対する「新鮮な」アプローチがあるということです。悪い部分は、他の人があなたを信じるのに苦労するかもしれないということかもしれません。

行うべきことのランドリーリストを作成しないでください。ただし、緊急であると思われるものを1つ選択し、他の人が応答する可能性が最も高いものを1つ選択し、解決策を提案してください。うまくいけば、最初の成功の強さで、別の問題の別の解決策を提案してください。

しかし、少しずつゆっくりと考え、あなたのアイデアが新しいグループの間でゆっくりと「キャッチ」されることを願っています。

見たいサンプルを設定しますが、テストで別の開発者の視点を評価します：ある開発者は成功をテストし、別の開発者は失敗をテストします。

既存のテスト（ほとんどの場合）にはまだ目的がありますが、すぐには明らかにならない場合があります。すべてを一度にオーバーホールしてリファクタリングすることはお勧めしません（面倒でエラーが発生しやすいです）。悪いテストは、最終的に更新、書き換える必要があります。そうでない場合、ソフトウェアの進化に伴い、単純に時代遅れになる場合があります。

テストに対するアプローチがいくつかの点で優れている場合、人々はそのモデルから学習するか、支援を求めます。バランスの取れたリソースがありますが、テストをサポートするために必要に応じて拡張できます。

最終的には、テストを介してプログラムの品質を向上させ、カバレッジを改善する必要があります。テストに重点を置き、良い例を設定することでこれを行うことができますが、他の人の視点に感謝します。

重要性を強調する場合、テストの運用環境を変えることができます。1つの明白な例は、テストを並行して実行することです。再入可能でない場合は、プログラムまたはテストのバグ（win / win）を見つけました。より厳格なテスト環境では、不良テストの修正および/または書き換えが強制されます（2回目の正しい方法が望ましい）。そのような変更をゆっくりと導入し（テストの半分を一度に壊さないでください-これは本当の問題です）、何が良いテストであり、最終的には良いプログラムであるかを学ばせます。次に、あなたと他の人がテストに参加して変更/修復/拡張するときに、学んだことを適用します-それは漸進的であり、その時点でコンテキスト/プログラムをよりよく理解できます。

時間をかけて修正する

私は同じ状況にありました。毎朝1時間かけてテストを行い、すべてが修正されるまで修正しました。それは中規模のコードベースであり、1.5か月で終了したと思います。また、テストに自信を持ちました。

良いテストである限り、テストが単体テストであるか統合テストであるかは個人的に気にしません。良いテストでは、私はそれを意味します：

• 自動的にクリーンアップします
• 繰り返し可能です
• 環境相互作用を最小限に抑える
• 一貫している

途中で、私はより良いテスト構築を伝道しました（つまり、私は多くの人を悩ませました）。