はじめに

ソフトウェア開発のアンチパターンに関するいくつかの記事があります。 しかし、彼らのほとんどは、コードレベルで詳細について話し、特定のテクノロジーまたはプログラミング言語に焦点を当てています。



この記事では、一歩下がって、すべてに共通するテストの高レベルのアンチパターンをリストしたいと思います。 プログラミング言語に関係なく、それらのいくつかを学んでいただければ幸いです。

用語

残念ながら、テストではまだ一般的な用語が開発されていません。 統合テスト、エンドツーエンドテスト、コンポーネントテストの違いは何ですか？百人の開発者に尋ねると、100種類の答えが得られます。 この記事では、そのようなテストのピラミッドに限定します。









テストピラミッドを見たことがない場合は、慣れることを強くお勧めします。 始めるのに役立つ記事をいくつか紹介します。

• 「テスト自動化ピラミッドの忘れられたレイヤー」 （Mike Cohn、2009）
• テストピラミッド （Martin Fowler、2012）
• Googleテストブログ （Google 2015）
• テストピラミッドの実践 （Ham Fokke、2018）

テストピラミッド自体は、特に各カテゴリに必要なテストの数の観点から、個別の議論に値します。 ここでは、単純にそれを参照して、テストの下位2つのカテゴリを定義します。 この記事ではユーザーインターフェイステスト（ピラミッドの上部）については言及していません。これは主に簡潔にするためと、独自のアンチパターンがあるためです。



したがって、テストの2つの主要なカテゴリを定義します：単体テスト（単体テスト）と統合テスト。

テスト	目的	が必要です	スピード	難易度	セットアップが必要
単体テスト	クラス/メソッド	ソースコード	とても速い	低い	いや
統合テスト	コンポーネント/サービス	稼働中のシステムの一部	ゆっくり	平均的	はい

単体テストは 、名前と意味の両方でより広く知られています。 これらのテストはソースコードに付随し、直接アクセスできます。 通常、 xUnitフレームワークまたは同様のライブラリを使用して実行されます。 単体テストはソースで直接動作し、すべてを完全に理解しています。 1つのクラス/メソッド/関数（またはこの特定の機能の最小作業単位）がテストされ、他のすべてがシミュレート/置換されます。



統合テスト （サービステストまたはコンポーネントテストとも呼ばれます）は、コンポーネント全体に焦点を当てています。 クラス/メソッド/関数のセット、モジュール、サブシステム、さらにはアプリケーション自体でもかまいません。 入力を渡し、出力を調べることにより、コンポーネントをテストします。 通常、何らかの事前展開または構成が必要です。 外部システムは完全にシミュレートまたは置換でき（たとえば、実際のDBMSではなくメモリ内のDBMSを使用）、状況に応じて実際の外部依存関係が使用されます。 単体テストと比較して、テスト環境を準備するか、テスト環境と対話するには、より専門的なツールが必要です。



2番目のカテゴリは、あい​​まいな定義に苦しんでいます。 これは、名前をめぐる最も論争の的となっている場所です。 統合テストの「領域」も、特にアプリケーションへのアクセスの性質の点で非常に矛盾しています（ ブラックボックスまたはホワイトボックスでテストします。 モックオブジェクトは許可されるかどうか）。



基本的な経験則は、テストが...

• データベースを使用する
• ネットワークを使用して別のコンポーネント/アプリケーションを呼び出し、
• 外部システム（キューやメールサーバーなど）を使用します
• ファイルの読み取り/書き込み、または他の入力/出力操作の実行、
• ソースコードではなく、アプリケーションバイナリに依存しています。

...これは統合であり、単体テストではありません。



用語を理解したら、アンチパターンのリストに飛び込むことができます。 それらの順序は、その有病率にほぼ対応しています。 最も一般的な問題は最初にリストされています。

ソフトウェアテストのアンチパターンのリスト

1. 統合なしの単体テスト
2. モジュールなしの統合テスト
3. 無効なテストタイプ
4. 間違った機能をテストする
5. 内部実装テスト
6. テスト範囲に対する過度の注意
7. 信頼性の低いテストまたは遅いテスト
8. 手動テストの実行
9. テストコードへの不十分な注意
10. 本番環境からの新しいバグのテストを作成できない
11. 宗教としてのTDDに関連する
12. 最初にドキュメントを読まずにテストを書く
13. 無知からのテストに対する態度が悪い

アンチパターン1.統合なしの単体テスト

これは、中小企業にとって古典的な問題です。 アプリケーションの場合、単体テスト（ピラミッドのベース）のみが作成され、それ以上は作成されません。 通常、統合テストの欠如は、次のいずれかの問題が原因です。

1. 同社には上級開発者はいません。 大学を卒業したばかりの後輩だけがいます。 彼らはユニットテストのみに会った。
2. ある時点で、統合テストは存在していましたが、有用であるよりも多くの問題を引き起こしたため、それらは放棄されました。 単体テストはメンテナンスがはるかに簡単なので、それらだけが残されました。
3. アプリケーション環境は「複雑」すぎて設定できません。 本番環境で「テスト済み」の機能。

最初の段落については何も言えません。 各効果的なチームには、他の開発者に優れた実践を示す一種のメンター/リーダーが必要です。 2番目の問題は、アンチパターン5、7 、および8で詳細に説明されています。



これにより、最後の質問-テスト環境の複雑な設定-に至ります。 誤解しないでください。一部のアプリケーションはテストが非常に困難です。 かつて、ホストに特別な機器を必要とする一連のRESTアプリケーションを使用する必要がありました。 この装置は生産時にのみ存在していたため、統合テストは非常に困難でした。 しかし、これは極端なケースです。



一般的な企業が作成した通常のWebまたはサーバーアプリケーションの場合、テスト環境のセットアップは問題になりません。 仮想マシンの出現と、最近のコンテナにより、今まで以上に簡単になりました。 基本的に、構成が困難なアプリケーションをテストしようとする場合、テスト自体を実行する前に、まず構成プロセスを修正する必要があります。



しかし、なぜ統合テストがそれほど重要なのでしょうか？



実際には、統合テストのみがいくつかのタイプの問題を検出できます。 標準的な例は、DBMS操作に関連するすべてのものです。 トランザクション、トリガー、およびストアドデータベースプロシージャは、それらに影響を与える統合テストを使用してのみ検証できます。 ユーザーまたは外部チームが開発した他のモジュールへの接続には、統合テストが必要です（これらは契約テストでもあります）。 パフォーマンスを検証するテストは、定義による統合テストです。 統合テストが必要な理由の概要を以下に示します。

問題の種類	単体テストで定義	統合テストで定義
コアビジネスロジック	はい	はい
コンポーネント統合の問題	いや	はい
取引	いや	はい
DBトリガー/プロシージャ	いや	はい
他のモジュール/ APIとの誤った契約	いや	はい
他のシステムとの誤った契約	いや	はい
パフォーマンス/タイムアウト	いや	はい
相互/自己リセットロック	たぶん	はい
クロスセキュリティの問題	いや	はい

通常、クロスアプリケーションの問題には統合テストが必要です。 マイクロサービスの現在の狂気を考えると、統合テストはあなた自身のサービス間で契約を結んでいるので、さらに重要になっています。 これらのサービスが他のグループによって開発されている場合、インターフェイスコントラクトに違反しているかどうかを自動的に確認する必要があります。 これは、統合テストでのみカバーできます。



要約すると、非常に孤立したもの（Linuxコマンドラインユーティリティなど）を作成していない場合、単体テストでは見つからない問題を見つけるための統合テストが本当に必要です。

アンチパターン2.モジュールなしの統合テスト

これは、以前のアンチパターンの反対です。 大企業や大企業のプロジェクトではより一般的です。 ほとんどの場合、この状況は、単体テストには本当の価値はなく、リグレッションをキャッチできるのは統合テストだけだと考えている開発者に関連しています。 多くの経験豊富な開発者は、単体テストが時間の無駄だと感じています。 通常、それらを尋ねると、マネージャーは過去に一度、テストでコードカバレッジを増やすことを要求し（ アンチパターン6を参照）、簡単な単体テストを書くことを強制することがわかります。



実際、理論的には、プロジェクトには統合テストしかありません。 しかし実際には、そのようなテストは非常に高価になります（開発時間とアセンブリ時間の両方）。 前のセクションの表では、統合テストでもビジネスロジックエラーを検出できるため、単体テストを「置換」できることがわかりました。 しかし、そのような戦略は長期的に実行可能ですか？

統合テストは複雑です

例を考えてみましょう。 このような4つのメソッド/クラス/関数を持つサービスがあるとします。









各モジュールの数字は、その循環的な複雑さ、つまりプログラムコードのこの部分を通る線形独立ルートの数を示しています。



開発者のMaryはチュートリアルを実行し、このサービスの単体テストを作成します（ユニットテストの重要性を理解しているため）。 考えられるすべてのシナリオを完全にカバーするには、いくつのテストを書く必要がありますか？



当然、これらのモジュールのビジネスロジックを完全にカバーする2 + 5 + 3 + 2 = 12の独立した単体テストを作成できます。 この番号は1つのサービスのみのものであり、Maryが取り組んでいるアプリケーションには複数のサービスがあることに注意してください。



開発者Joe Gruntは、単体テストの価値を信じていません。 彼はこれは時間の無駄だと信じており、このモジュールの統合テストのみを書くことにしました。 いくら 彼は、サービスのすべての部分を通るすべての可能なルートを調べ始めます。







繰り返しますが、2 * 5 * 3 * 2 = 60のコードパスが可能であることは明らかです。 これは、Joeが実際に60の統合テストを書くことを意味しますか？ もちろん違います！ 彼はcになります。 最初に、彼は「代表的」と思われる統合テストのサブセットを選択しようとします。 この「代表的な」サブセットは、最小限の労力で十分なカバレッジを提供します。



理論的には、すべてが単純ですが、実際には問題がすぐに発生します。 実際には、これらの60のシナリオは同じ方法で作成されていません。 それらのいくつかは境界線の場合です。 たとえば、3つのコードパスがモジュールCを通過します。 それらの1つは非常に特殊なケースです。 CがコンポーネントBから特定の入力を受け取った場合にのみ再作成できます。コンポーネントBはそれ自体が境界線であり、コンポーネントAからの特別な入力によってのみ取得できます。したがって、この特定のシナリオでは、コンポーネントCの特別な条件



一方、Maryは、単純な単体テストを使用して、複雑さを増すことなく境界線のケースを単純に再作成します。









メアリーは単体テストのみを書くのでしょうか？ 結局、これは彼女をアンチパターン1に導きます。 これを回避するために、彼女は単体テストと統合テストの両方を作成します。 実際のビジネスロジックのすべての単体テストを保存し、1つまたは2つの統合テストを記述して、システムの残りの部分（つまり、これらのモジュールが仕事をするのに役立つ部分）が正常に動作していることを確認します。



統合テストでは、残りのコンポーネントに焦点を当てる必要があります。 単体テストは、ビジネスロジック自体を処理できます。 Maryの統合テストは、シリアル化/逆シリアル化、キュー通信、およびシステムデータベースに焦点を当てます。









その結果、統合テストの数は、この記事の最初のセクションのテストのピラミッドの形式に対応するユニットテストの数よりもはるかに少なくなります。

統合テストが遅い

統合テストの2番目の大きな問題は、速度です。 原則として、統合テストは単体テストよりも1桁遅く実行されます。 単体テストに必要なのは、アプリケーションのソースコードのみで、それ以外は必要ありません。 ほとんどの場合、CPU負荷によって制限されます。 一方、統合テストでは外部システムとの入出力操作を実行できるため、それらを最適化することははるかに困難です。



時差を把握するために、次の数値を想定します。

• 各ユニットテストには60ミリ秒（平均）かかります。
• 各統合テストには800ミリ秒（平均）かかります。
• 前のセクションで示したように、アプリケーションには40のサービスがあります。
• Maryは、サービスごとに10の単体テストと2つの統合テストを作成します。
• Joeは、各サービスに対して12の統合テストを作成します。

カウントしましょう。 Joeは、Maryと同じコードカバレッジを提供する（実際にはそうではない）統合テストの完全なサブセットを見つけたと言われています。

リードタイム	統合テストのみ（Joe）	単体テストと統合テストの実施（メアリー）
単体テストのみ	N / a	24秒
統合テストのみ	6.4分	64秒
すべてのテスト	6.4分	1.4分

全体の動作時間の差は非常に大きいです。 各コード変更後の1分間の待機は、6分間の待機とは大きく異なります。 また、各統合テストの800ミリ秒の仮定は非常に控えめです。 1つのテストに数分かかる統合テストスイートを見ました。



まとめると、ビジネスロジックをカバーするために統合テストのみを使用しようとすると、膨大な時間の浪費になります。 CIを使用してテストを自動化しても、フィードバックループ（コミットからテスト結果の受信まで）は依然として非常に長くなります。

統合テストは単体テストよりもデバッグが難しい

統合テスト（単体テストなし）のみに限定することが推奨されない最後の理由は、失敗したテストをデバッグする時間です。 統合テストは、定義により、いくつかのソフトウェアコンポーネントをテストするため、テストされたコンポーネントのいずれかによって障害が発生する場合があります。 問題を特定することは、より多くのコンポーネントが関与するほど難しくなります。



統合テストが失敗した場合、失敗の原因とその修正方法を理解する必要があります。 統合テストの複雑さと範囲により、デバッグは非常に困難です。 繰り返しますが、例として、アプリケーションに対して統合テストのみが行われたと仮定します。 これが典型的なオンラインストアだとしましょう。



同僚（またはあなた）が新しいコミットを送信すると、統合テストの起動が開始され、次の結果が得られます。









開発者として、結果を見て、「顧客が商品を購入する」という名前の統合テストに合格しないことを確認します。 オンラインストアアプリケーションのコンテキストでは、これはあまり良くありません。 このテストに合格しない理由はたくさんあります。



テスト環境のログとメトリックに突入せずにテストの失敗の原因を見つけることは不可能です（それらが問題を特定するのに役立つと仮定して）。 場合によって（およびより複雑なアプリケーション）、統合テストを真にデバッグする唯一の方法は、コードを抽出し、ローカルマシンでテスト環境を再作成し、統合テストを実行して、ローカル開発環境で障害を再現することです。



ここで、このアプリケーションでMaryと作業しているため、統合テストと単体テストの両方があるとします。 同僚がコミットを送信すると、すべてのテストを実行し、次のものを取得します。









現在、2つのテストが失敗しています。

• 「顧客が商品を購入する」は、以前のように合格しません（統合テスト）。
• 「特別割引テスト」も失敗します（単体テスト）。

これで、問題を探す場所を非常に簡単に理解できます。 割引機能のソースコードに直接アクセスして、エラーを見つけて修正することができます。99％の場合、統合テストもデバッグされます。



単体テストは、統合テストの前に、または統合テストと同時に失敗します。エラーを見つける必要がある場合は、はるかに簡単なプロセスです。

ユニットテストが必要な理由の簡単な結論

これはこの記事の最も長いセクションでしたが、非常に重要だと思います。 要約すると、 理論的には統合テストのみを使用できますが、実際には

1. 単体テストは保守が簡単です。
2. 単体テストでは、境界線のケースやまれな状況を簡単に再現できます。
3. 単体テストは、統合テストよりもはるかに高速に実行されます。
4. 失敗した単体テストは、統合テストよりも簡単に修正できます。

統合テストしかない場合、開発時間と会社のお金の両方を無駄にします。 単体テストと統合テストの両方が同時に必要です。 それらは相互に排他的ではありません。 1つのタイプのテストのみの使用を促進するいくつかのオンライン記事があります。 これらの記事はすべて、誤った情報を広めています。 悲しいことに、そうです。

アンチパターン3.間違ったタイプのテスト

これで、両方のタイプのテスト（ユニットと統合）が必要な理由がわかりました。 各カテゴリで必要なテストの数を決定する必要があります。



明確で明確なルールはありません。 すべてはアプリケーションに依存します。 どのタイプのテストがアプリケーションにとってより価値があるかを判断するのに時間がかかることを理解することが重要です。 テストピラミッドは、テストの数に関する単なる仮定です。 彼女はあなたが商用ウェブアプリケーションを書いていると仮定しますが、これは常にそうではありません。 いくつかの例を見てみましょう。

例：Linuxコマンドラインユーティリティ

アプリケーションはコマンドラインユーティリティです。 1つの形式（CSVなど）のファイルを受け取り、いくつかの変換を実行して、別の形式（JSONなど）にエクスポートします。 アプリケーションはスタンドアロンであり、他のシステムと通信せず、ネットワークも使用しません。 変換は、アプリケーションの適切な動作に不可欠な複雑な数学的プロセスです（作業の速度に関係なく、常に正しく実行する必要があります）。



そのような例に必要なもの：

• 数学的計算のための多くの単体テスト。
• CSVの読み取りとJSONの書き込みのためのいくつかの統合テスト。
• グラフィカルインターフェイスがないため、GUIテストはありません。

このようなプロジェクトのテストの「ピラミッド」は次のとおりです。









ここでは単体テストが支配的であり、結果のフォームはピラミッドではありません 。

例：支払い管理

既存のエンタープライズシステムの大規模なコレクションに統合する新しいアプリケーションを追加しています。 このアプリケーションは、外部システムの支払い情報を処理する支払いゲートウェイです。 この新しいアプリケーションは、すべてのトランザクションのログを外部データベースに保存し、外部の支払いプロバイダー（Paypal、Stripe、WorldPayなど）と通信し、請求書を作成する別のシステムに支払いデータを送信する必要があります。



そのような例に必要なもの：

• ビジネスロジックがないため、ユニットテストはほとんどありません。
• 外部通信、データベースストレージ、課金システムの多くの統合テスト。
• グラフィカルインターフェイスがないため、GUIテストはありません。

このようなプロジェクトのテストの「ピラミッド」は次のとおりです。









ここでは統合テストが支配的であり、結果のフォームは再びピラミッドではありません 。

例：サイトビルダー

あなたは、サイトを作成するための革新的な方法を開発した完全に新しいスタートアップに取り組んでいます：ユニークなブラウザベースのWebアプリケーションビルダー。



このアプリケーションは、Webページに追加できるすべての可能なHTML要素のセットと、既製のテンプレートのライブラリを持つグラフィックデザイナーです。 市場で新しいテンプレートを購入することは可能です。 コンストラクターは非常に使いやすく、コンポーネントをページにドラッグアンドドロップしたり、サイズを変更したり、プロパティを編集したり、色や外観を変更したりできます。



この不自然な例に必要なもの：

• ビジネスロジックがないため、ユニットテストはほとんどありません。
• 市場と対話するためのいくつかの統合テスト。
• GUIが適切に機能することを確認するための多くのGUIテスト。

このようなプロジェクトのテストの「ピラミッド」は次のとおりです。









ここではUIテストが支配的であり、結果のフォームは再びピラミッドではありません 。



これらの極端な状況は、さまざまなアプリケーションがさまざまなテストの組み合わせを必要とすることを示しています。 個人的には、統合テストなしの支払い管理アプリケーション、およびUIテストなしのWebサイトデザイナーを見ました。



インターネットでは、統合テスト、単体テスト、UIテストの特定の比率を呼び出す記事を参照できます（私はそれらを参照しません）。 これらの記事はすべて、プロジェクトで機能しない可能性のある仮定に基づいています。

アンチパターン4.間違った機能のテスト

前のセクションでは、アプリケーションに必要なテストの種類と数について説明しました。 次の論理ステップは、テストする必要がある機能の種類を説明することです。



理論的には、究極の目標はコードの100％をカバーすることです。 実際には、この目標を達成することは難しく、バグがないことを保証するものではありません。



場合によっては、アプリケーションのすべての機能を確認することが非常に現実的です。 プロジェクトをゼロから開始し、正しく動作し、テストに必要な労力を考慮に入れた小さなチームで作業する場合、追加されたすべての機能をテストでカバーすることはまったく普通です（既存のコードのテストが既にあるため）。



しかし、すべての開発者が幸運なわけではありません。 ほとんどの場合、最小限のテストで（またはまったくテストなしで）既存のアプリケーションを継承します。 大規模で定評のある会社で働く場合、レガシーコードを扱うことは例外というよりもルールです。



理想的には、新しいレガシーアプリケーションコードと既存のレガシーアプリケーションコードの両方のテストを作成するのに十分な時間が与えられます。 このロマンチックなアイデアは、プロジェクトマネージャーによって拒否される可能性があります。プロジェクトマネージャーは、テスト/リファクタリングよりも新しい機能の追加に関心があります。 新しい機能を追加すること（上司の要求に応じて）と既存のテストスイートを拡張することのバランスを優先し、見つける必要があります。



それでは、正確に何をテストするのでしょうか？ 何に焦点を合わせますか？ 何度か、開発者がアプリケーションの全体的な安定性に実質的に意味のない単体テストの作成に貴重な時間を費やしているのを見ました。 役に立たないテストの標準的な例は、アプリケーションデータモデルを検証する簡単なテストです。



コードカバレッジは、個別のアンチパターンで詳細に分析されます。 同じセクションで、コードの「重要性」とテストとの関係について説明します。



開発者にアプリケーションのソースコードを表示するように依頼すると、おそらくブラウザでIDEまたはコードリポジトリが開き、別のフォルダーが表示されます。









これは物理コードモデルです。ソースコードを含むファイルシステム内のフォルダーが表示されます。この階層はコード自体を操作するのに最適ですが、残念ながら重要性を示していません。フォルダのフラットリストは、そこに含まれるすべてのコードコンポーネントが同じ意味を持つことを意味します。



コードの異なるコンポーネントはアプリケーションの全体的な機能に異なる影響を与えるため、これは当てはまりません。簡単な例として、オンラインストアアプリケーションを作成していて、本番環境で2つのエラーが発生したとします。

1. 顧客はバスケットから商品の代金を支払うことができず、すべての販売が停止しました。
2. 顧客は、製品を表示するときに誤った推奨事項を受け取ります。

両方のエラーを修正する必要がありますが、最初のエラーは明らかに高い優先度です。したがって、テストをまったく行わずにオンラインストアアプリケーションを入手した場合は、推奨メカニズムではなく、バスケットの機能を直接確認する新しいテストを作成する必要があります。推奨メカニズムとごみ箱はファイルシステム内の同じレベルのフォルダーにある可能性があるにもかかわらず、テスト中の重要度は異なります。



要約すると、中規模または大規模のアプリケーションでは、遅かれ早かれ、開発者はコードの異なる表現、つまりメンタルモデルを持ちます。









ここには3つのコード層が示されていますが、アプリケーションのサイズによっては、さらに多くの層がある場合があります。 これは：

1. 重要なコードは、頻繁に障害が発生するコードであり、ほとんどの新機能が導入されており、ユーザーにとって重要です。
2. , .
3. , .

このようなメンタルモデルは、新しいソフトウェアテストを作成するたびに留意する必要があります。テストを作成している機能が重要なコードまたはコアコードに関連しているかどうかを尋ねます。その場合、テストを作成します。そうでない場合は、他の何か（たとえば、別のバグ）に時間を費やすことが理にかなっています。



コードの重要性の概念は、アプリケーションにとってどのコードカバレッジで十分かという永遠の疑問に答えるのにも役立ちます。答えるには、アプリケーションコードの重要度レベルを自分で知るか、知っている人に尋ねる必要があります。この情報が得られたら、答えは明らかです。重要なコードの 100％をカバーするテストを作成してみてください。すでにこれを行っている場合は、100％をカバーするテストを作成してみてくださいメインコード。ただし、テストで全コードの100％をカバーすることはお勧めできません。



重要なコードは常に一般的なコードの小さなサブセットにすぎないことに注意することが重要です。したがって、重要なコードがたとえば全体の20％である場合、テストを一般的なコードの20％でカバーすることは、実稼働環境でのバグの数を減らすための適切な最初のステップです。



一般に、次のコードの単体テストと統合テストを作成します。

• しばしば壊れる
• しばしば変わる
• ビジネスクリティカル

テストスイートをさらに拡張する時間がある場合は、重要性がほとんどないかまったくないテストに時間を費やす前に、テストスイートの効果の低下に注意してください。

アンチパターン5.内部実装のテスト

より多くのテストは常に良いです。 そう？



間違った！また、テストが実際に適切に構造化されていることを確認する必要があります。テストの記述が間違っていると、二重の損傷が発生します。

• 最初に、彼らは貴重な開発者の時間を書いて費やす。
• 次に、やり直さなければならないとき（新しい関数を追加するとき）に、さらに多くの時間を費やします。

厳密に言えば、テストコードは他のコードと同じです。ある時点で、徐々にそれを改善するためにリファクタリングが必要になります。しかし、新しい機能を追加するときに既存のテストを定期的に変更する場合、テストは必要なものをテストしていません。



企業がどのように新しいプロジェクトを立ち上げ、今度はすべてを正しく行うと思うかを見ました。すべての機能をカバーするために多くのテストを書き始めます。しばらくすると、新しい関数が追加されます。そのためには、いくつかの既存のテストを変更する必要があります。次に、別の関数を追加し、さらに多くのテストを更新します。すぐに、既存のテストをリファクタリング/修正するための労力は、実際に機能自体を実装するのに必要な時間を超えます。



そのような状況では、一部の開発者は単にあきらめます。彼らは、テストは時間の無駄だと主張し、新しい機能に完全に焦点を合わせるために、既存のテストスイートを放棄しています。いくつかの例外的なケースでは、テストの失敗によりリリースでさえ遅れます。



もちろん、ここでの問題はテストの質の低さです。常にリファクタリングが必要な場合は、メインコードとの接続が近すぎます。残念ながら、このような「誤って記述された」テストを特定するには、ある程度の経験が必要です。



新しい関数が表示されたときに多数の既存のテストを変更することは、単なる症状です。。本当の問題は、テストが内部実装をテストすることです。これは常に災害シナリオです。いくつかのソフトウェアテストガイドがこの概念を説明しようとしていますが、明確な例でそれを実証するものはほとんどありません。



記事の冒頭で、特定のプログラミング言語について話すことはないと約束しました。約束を守ります。ここの図は、お気に入りの言語のデータ構造を示しています。それらは、フィールド/値を含む構造/オブジェクト/クラスと考えてください。



オンラインストアアプリケーションのCustomerオブジェクトが次のようになっているとします。









Customerタイプは2つの値のみを受け入れます0



は「ゲスト」を意味し、 1



は「登録ユーザー」を意味します。 開発者はオブジェクトを見て、「ゲスト」と「登録ユーザー」の10個をチェックするために10個のユニットテストを作成します。 そして、「検証用」と言うとき、テストはこの特定のオブジェクトのこの特定のフィールドを検証することを意味します 。



時間が経つと、マネージャーは、値2



新しいタイプのユーザーがブランチに必要であると判断します。 開発者は、アフィリエイト向けにさらに10個のテストを追加しています。 最後に、「プレミアムカスタマー」と呼ばれる別のタイプのユーザーが追加され、開発者はさらに10個のテストを追加します。



現在、4つのカテゴリに40のテストがあり、それらはすべてこれらの特定のフィールドをチェックします。 （数字は架空のもので、例はデモンストレーション用です。実際のプロジェクトでは、6つのネストされたオブジェクトと200のテストで10の相互接続されたフィールドがあります）。







経験豊富な開発者であれば、イベントのさらなる発展を想像できます。 新しい要件があります：

1. 登録ユーザーの場合は、さらにメールを保存する必要があります。
2. 支店のユーザーについては、会社名を保存する必要があります。
3. プレミアムユーザーにはボーナスポイントが付与されます。

クライアントオブジェクトは次のように変更されます。







これで、外部キーに関連付けられた4つのオブジェクトがあり、それらがチェックするフィールドがもはや存在しないため、40個のテストすべてがすぐに中断します。



もちろん、この些細な例では、テストとの後方互換性に違反しないように、既存のフィールドを単純に保存できます。 実際のアプリケーションでは、これは常に可能とは限りません。 下位互換性は、基本的に、古いコードと新しいコード（新しい関数の前後）の両方を保存する必要があることを意味し、これによりコードが大きく膨張します。 また、単体テストのために古いコードを保存すること自体が明らかなアンチパターンであることに注意してください。



これが実際の状況で発生すると、開発者はテストを修正するために余分な時間を要求します。 プロジェクトマネージャーは、ユニットテストは新しい機能の実装を妨げるため、時間の無駄であると述べています。 その後、チーム全体がテストスイートを拒否し、失敗したテストをすぐに無効にします。



ここでの主な問題はテストではなく、テストとしてです。 内部実装の代わりに、予想される動作をテストする必要があります。 単純な例では、オブジェクトの内部構造を直接テストする代わりに、それぞれの場合に正確なビジネス要件を検証する必要があります。 同じテストを実装する方法は次のとおりです。







ここでは、テストはオブジェクトの内部構造をまったくチェックしません。 他のオブジェクト/メソッド/機能との相互作用のみをチェックします。 必要に応じて、他のオブジェクト/メソッド/機能をシミュレートする必要があります。 各タイプのテストは、技術的な実装ではなく、特定のビジネス要件に直接対応していることに注意してください（常に良い方法です）。



オブジェクトの内部実装を変更する場合、テスト検証コードは同じままです。 変更できるのは各テストのセットアップコードのみです。これらのコードは、1つの補助関数createSampleCustomer()



または同様のものに集中的に保存する必要があります（詳細については、 アンチパターン9を参照）。



もちろん、理論的に検証されたオブジェクト自体は変わる可能性があります。 実際には、 loginAsGuest()



、 register()



、 showAffiliateSales()



、およびgetPremiumDiscount()



を同時に変更するのは非現実的です。 現実的なシナリオでは、40個ではなく10個のテストをリファクタリングする必要があります。



要約すると、新しい関数が追加されるときに既存のテストを絶えず修正する場合、これはテストが内部実装に密接に関連していることを意味します。

アンチパターン6.テストカバレッジへの過度の注意

コードカバレッジは、業界で人気のある指標です。 開発者とプロジェクトマネージャーの間では、テストでコードをカバーするために必要なことについて無限の 議論があります。



カバレッジは簡単に測定できる指標であるため、誰もがカバレッジについて話すのが大好きです。 ほとんどのプログラミング言語とテストフレームワークには、表示するためのシンプルなツールがあります。



少し秘密を教えてください 。コードカバレッジはまったく役に立たないメトリックです。 「正しい」インジケータはありません。 これはtrapの質問です。 バグや問題がまだ残っているコードカバレッジが100％のプロジェクトがあるかもしれません。 実際には、他のメトリック-よく知られているCTM（Codepipes Testing Metrics）メトリックを追跡する必要があります。

CTMメトリック

これらに精通していない場合のCTM定義は次のとおりです。

メトリック名	説明	理想値	正常値	問題値
PDWT	テストを書いている開発者の割合	100％	20％-70％	100％未満
Pbcnt	新しいテストの作成につながるバグの割合	100％	0％-5％	100％未満
PTVB	行動テストの割合	100％	10％	100％未満
PTD	決定論的テストの割合	100％	50％-80％	100％未満

PDWT （テストを作成する開発者の割合）は、おそらく最も重要な指標です。 テストがまったくない場合、ソフトウェアテストのアンチパターンについて話すことは意味がありません。 チームのすべての開発者はテストを作成する必要があります。 新しい関数は、1つ以上のテストを伴う場合にのみ、 完了と宣言できます。



PBCNT （新しいテストの作成につながるバグの割合）。 本番環境のすべてのバグは、対応する修正をチェックする新しいテストを作成する大きな理由です。 バグは本番環境に一度しか現れないはずです。 プロジェクトが最初の「修正」後でも繰り返しバグに苦しんでいる場合、チームはこのメトリックを使用することで本当に恩恵を受けます。 詳細については、 アンチパターン10を参照してください。



PTVB （実装ではなく、動作をテストするテストの割合）。 密接に結合されたテストは、メインコードのリファクタリングに多くの時間を消費します。 このトピックは、 アンチパターン5ですでに説明されています。



PTD （合計の決定論的テストの割合）。 テストは、ビジネスコードに問題がある場合にのみ失敗します。 明らかな理由がないためにテストが定期的に中断する場合、これは大きな問題であり、 antipater 7で説明されています。



メトリックについて読んだ後でも、コードをカバーするためにハードメトリックを設定することを主張している場合、数値20％を提供します。 この数値は、パレートの法則に基づいた経験則として使用する必要があります。 コードの20％でエラーの80％が発生するため、テストの作成を本当に開始したい場合は、このコードで最初に開始することをお勧めします。 このヒントは、 アンチパターン4ともよく一致しています。ここでは、主に重要なコードのテストを記述することをお勧めします。



カバレッジ全体の100％に到達しようとしないでください。 これは理論上は良いように聞こえますが、ほとんどの場合時間の無駄です。

• 80％から100％への移行は0％から20％への移行よりもはるかに難しいため、力を無駄にします。
• コードカバレッジを増やすとフィードバックが少なくなります。

重要なアプリケーションでは、実行するために複雑な単体テストを必要とする特定のシナリオがあります。 このようなテストを記述するために必要な労力は、通常、これらのシナリオが運用環境で実装されるリスク（発生した場合）よりも重要です。



大規模なアプリケーションで作業した場合、70％または80％のカバレッジに達した後、残りのコードの有用なテストを作成することは非常に難しくなります。







アンチパターン4の説明で既に見たように、実際には一部のコードパスは本番環境で失敗することはないため、それらのテストを記述することは推奨されません。 実際の機能の実装に時間を費やすことをお勧めします。







プロジェクトにテストのコードカバレッジの一定の割合の条件がある場合、開発者は通常、簡単なコードをテストするか、基礎となるプログラミング言語をチェックするだけのテストを書くことを余儀なくされます。 これは膨大な時間の浪費であり、開発者としてあなたはそのような不合理な要件の管理に不平を言う義務があります。



要約すると、テストによるコードカバレッジは、ソフトウェアプロジェクトの品質の指標として使用できません 。

アンチパターン7.信頼性の低いテストまたは遅いテスト

特に、このアンチパターンは何度も 詳細に 議論さ れ て いるので、補足するだけです。



ソフトウェアテストはリグレッションの初期の指標であるため、常に確実に機能するはずです。 テストの失敗は懸念の原因であり、対応するビルドの責任者はテストが失敗した理由のチェックを開始する必要があります。



このアプローチは、決定論的な方法に該当するテストでのみ機能します。 テストが失敗することがあり、パスする場合があります（チェック間でコードを変更せずに）、それは信頼できず、すべてのテストの信用を失います。 これは二重のダメージを与えます：

• 開発者はテストを信頼しなくなり、テストを無視し始めます。
• 通常のテストでさえも、不確定な結果の海では検出が困難になります。

アセンブリ全体のステータスが変更されるため、失敗したすべてのチームメンバーに失敗したテストを明確に通知する必要があります。 一方、信頼性の低いテストが存在する場合、新しい障害が発生したのか、それとも古い信頼性のないテストの結果なのかを理解することは困難です。









少数の信頼性の低いテストでさえ、他人に対する信頼を破壊するのに十分です。 たとえば、5つの信頼できないテストがあり、テストを通じて新しいビルドを実行し、3つの失敗を受け取りました。 すべてが正常であるか、3つの回帰があるかは明らかではありません。



非常に遅いテストでの同様の問題。 開発者は、各コミットの結果に関する迅速なフィードバックを必要とします（これについては次のセクションでも説明します）。そのため、最終的に遅いテストを無視するか、まったく実行しません。



実際には、信頼性の低い低速のテストはほとんどの場合、統合テストやユーザーインターフェイステストです。 テストのピラミッドを登るにつれて、信頼できないテストの可能性が大幅に増加します。 テストがブラウザイベントを処理する場合、確定的にするのは難しいことが知られています。 多くの要因が不安の原因になる可能性がありますが、テスト環境とその要件は通常、責任があります。



信頼性の低い低速なテストに対する主な保護は、テストセットを個別のテストセットに分離することです（ただし、これらのテストが正しくない場合）。 インターネットには、プログラミング言語でそのようなテストを修正する方法に関する多くのリソースがあるため、ここで説明するのは意味がありません。



要約すると、絶対に信頼できるテストのセットが必要です。テストのセット全体のサブセットのみにしてください。 このセットのテストが失敗した場合、問題はコードと明確になります。 このようなテストに失敗すると、コードを実稼働環境に入れることはできません。

アンチパターン8.テストを手動で実行する

さまざまな組織がさまざまな種類のテストを使用しています。 単体テスト、負荷テスト、ユーザー受け入れテスト（UAT）は、コードが実稼働環境にリリースされる前に実行できるテストスイートの典型的なカテゴリです。



理想的には、すべてのテストは人間の介入なしに自動的に実行されます。 これが不可能な場合は、少なくともコードの正確性を検証するテスト（つまり、単体テストと統合テスト） を自動的に実行する必要があります。 したがって、開発者は可能な限り迅速にコードに関するフィードバックを受け取ります。 関数は、コードが頭の中で新鮮で、コンテキストを別の関数にまだ切り替えていない場合、修正が非常に簡単です。









以前は、ソフトウェアライフサイクルの最も長いフェーズはアプリケーションの展開でした。 クラウドでは、マシンはオンデマンドで（VMまたはコンテナの形式で）作成されるため、新しいマシンの準備時間は数分または数秒に短縮されます。 このパラダイムシフトは、このような頻繁なサイクルに対応する準備ができていない多くの企業に驚きました。 既存のプラクティスのほとんどは、長いリリースサイクルに焦点を当てています。 手動の「前倒し」で特定のリリース時間を予想することは、会社が迅速な展開を約束している場合に放棄すべき時代遅れのプラクティスの1つです。



高速展開は、すべての展開における信頼を意味します。 自動展開の信頼性には、コードに対する高い信頼性が必要です。 この信頼を得るにはいくつかの方法がありますが、最初の防衛線はソフトウェアテストです。 ただし、回帰をすばやく検索できるテストスイートを用意することは、戦いの半分に過ぎません。 2番目の前提条件は、テストの自動実行（おそらく各コミット後）です。



多くの企業は 、継続的な供給や展開を実施していると考えています。 これは実際にはそうではありません。 真のCI / CDの実践とは、いつでもデプロイ可能なコードのバージョンがあることを意味します。 これは、リリース候補がすでにテストされていることを意味します。 したがって、まだ準備が整っていない「準備完了」パッケージの存在は、実際のCI / CDではありません。



ほとんどの企業は、人間の関与がエラーと遅延を引き起こすことを認識していましたが、テストの実行が半自動プロセスである企業はまだあります。 「半自動」とは、テストスイート自体を自動化できることを意味しますが、テスト環境の準備やテストを完了するためのテストデータのクリーニングなど、いくつかのメンテナンスタスクを実行します。 これは真の自動化ではないため、アンチパターンです。 テストのすべての側面を自動化する必要があります。









仮想マシンまたはコンテナにアクセスできるため、要求に応じてさまざまなテスト環境を簡単に作成できます。 リクエストごとにオンザフライでテスト環境を作成することは、組織の標準的なプラクティスです。 これは、それぞれの新しい機能が個別にテストされることを意味します。 問題のあるコンポーネント（つまり、テストが失敗する原因）は、展開の残りをブロックするべきではありません。



企業のテスト自動化のレベルを理解する簡単な方法は、QA /テストスタッフの日常業務を観察することです。 理想的には、テスターは既存のスイートに追加される新しいテストを作成するだけです。 手動で起動することはありません。 テストスイートはビルドサーバーによって実行されます。



要約すると、テストは常に舞台裏で行われるべきです。 開発者は、コミットの5〜15分後に特定の機能のテスト結果を見つけます。 テスターは新しいテストを作成し、既存のテストをリファクタリングしますが、手動で実行しないでください。

アンチパターン9.テストコードへの注意の欠如

経験豊富な開発者は、書き始める前に常に頭の中でコードを並べ替えるのにある程度の時間を費やすでしょう。 コード設計にはいくつかの原則があり、それらのいくつかは非常に重要であるため、ウィキペディアの別の記事でもそれらに専念しています。 以下に例を示します。

• ドライ
• キッス
• 固い

おそらく最初の原則が最も重要です。なぜなら、いくつかの関数で再利用される単一の真実のソースをコードに確立させるからです。 プログラミング言語に応じて、他のガイドラインとデザインパターンを使用することもできます。 チームによって具体的に行われた個別の推奨事項がある場合があります。



ただし、何らかの不明な理由により、一部の開発者はソフトウェアテストコードに同じ原則を適用していません。 関数コードが適切に設計されているプロジェクトを見ましたが、テストコードには、大量の重複、ハードコードされた変数、コピーペーストフラグメント、およびメインコードでは許されないと見なされるその他のエラーがあります。



長い目で見ればすべてのコードを維持する必要があるため、テストコードを二流と見なすことは意味がありません。 将来的には、テストを更新して作り直す必要があります。 それらの変数と構造は変化します。 デザインを考慮せずにテストを作成すると、追加の技術的負債が発生します。これは、メインコードの既存の負債に追加されます。



コンポーネントコードと同じ注意を払ってテストを書いてみてください。 ここでは、同じリファクタリング手法を使用する必要があります。 開始するには：

• すべてのテストコードを集中化する必要があります。 同様に、すべてのテストでテストデータを生成する必要があります。
• 検証の複雑なセグメントは、この領域の共通ライブラリに抽出する必要があります。
• 頻繁に使用される模倣やエミュレーションは、コピーペーストでコピーしないでください。
• テスト初期化コードは、同様のテストに共通する必要があります。

静的分析、ソースコードのフォーマット、またはコードの品質にツールを使用する場合は、テストコードも処理するようにツールを構成します。



要約すると、メインコンポーネントコードと同じくらい慎重にテストを設計します。

アンチパターン10.本番環境からの新しいバグのテストを記述できない

テストのタスクの1つは、回帰を見つけることです。 アンチパターン4で見たように、ほとんどのアプリケーションには、ほとんどのバグが現れるコードの「重要な」部分があります。 間違いを修正するときは、二度と起こらないようにする必要があります。 これを保証する最良の方法の1つは、修正テスト（単体テスト、統合テスト、またはその両方）を記述することです。



本番環境にリークするエラーは、テストを記述するための理想的な候補です。

• バグはすでに本番稼働を開始しているため、この分野でのテストの欠如を示しています。
• このエラーのテストを作成すると、将来のリリースも保護されます。

開発チームが（堅実なテスト戦略を使用していても） 本番環境で見つかったエラーのテストを作成しない場合、私はいつも驚かされます。 コードを修正し、すぐにエラーを修正します。 奇妙な理由で、多くの開発者は、テストの作成は新しい機能を追加するときにのみ重要であると想定しています。



真実から遠く離れた何かを想像することは困難です。実際のエラーから生じるテストは、新しい開発の一部として追加されるテストよりも価値があるとさえ言えます。最終的に、本番環境で新しい関数がクラッシュする頻度はわかりません（おそらく、クラッシュしない重要でないコードに属している可能性があります）。対応するテストは良好ですが、その値は疑わしいです。



しかし、本当の間違いのために書くテストは非常に貴重です。彼は修正の正確さをチェックするだけでなく、この領域でリファクタリングを行った後でも修正が常に機能することを確認します。



テストなしでレガシープロジェクトに参加する場合、これは有用なテストの実装を開始する最も明白な方法です。テストでカバーするコードを推測するのではなく、既存のバグに注意を払い、それらのテストを作成します。しばらくすると、テストはコードの重要な部分をカバーします。定義により、すべてのテストが頻繁に失敗するものをチェックするためです。私が提案した測定基準の 1つはこれらの努力を反映しています。



テストを拒否することが許される唯一のケースは、作業環境のエラーがコードに関連せず、環境自体に起因する場合です。たとえば、ロードバランサーの誤った構成は、単体テストを使用して修正できません。



要約すると、どのコードをテストするのかわからない場合は、本番環境に入るエラーを探してください。

アンチパターン11.宗教としてのTDDとの関係

TDDは、テストによる開発を意味します。これまでのすべての方法論と同様に、コンサルタントがこれが唯一の正しい決定であることを証明し始めるまで、それは紙の上で良いことです。この記事の執筆時点では、このプラクティスは段階的に廃止されていますが、完全性のために言及することにしました（企業界はこのアンチパターンの影響を特に受けるため）。



一般的に、ソフトウェアのテストに関しては：

1. テストは、対応するコードの前に記述できます。
2. テストは対応するコードと同時に記述できます。
3. テストは適切なコードの後に記述できます。
4. 特定のコードのテストを書く必要はまったくありません。

TDDの基本原則の1つは、常にオプション1（実装コードの前にテストを書く）に従うことです。これは一般的に良い習慣ですが、常に最良とは限りません。



コードの前にテストを記述することは、最終的なAPIに自信があることを意味しますが、常にそうであるとは限りません。明確な仕様があり、実装する必要があるすべてのメソッドの正確なシグネチャを知っている場合があります。しかし、場合によっては、すぐに最終バージョンではなく、何かを試すか、ソリューションの方向にコードを書くことができます。



実用的な観点から、同じスタートアップがTDDを盲目的にフォローするのは早いです。スタートアップで働いている場合、コードは非常に急速に変更される可能性があるため、TDDはあまり役に立ちません。 「正しい」オプションを記述するまで、コードをドロップして最初からやり直すこともできます。この場合、実装コードの後に​​テストを書くことが正しい戦略です。



一般的なテストの欠如（オプション4）も許容されます。アンチパターン4で見たように、一部のコードはまったくテストする必要がありません。些細なコードのテストを「TDDによる」と書いても何も得られません。



TDDの謝罪者による強制的なライティングテストへの執着は、まず健全な開発者の精神的健康にhealth大な被害をもたらしました。この強迫観念は繰り返し語られてきたので、繰り返す必要はないと思います（キーワード「TDD shit / stupid / dead」を検索してください）。



ここで、私自身が次のシナリオに従って何度か働いたことを認めたいと思います。

1. メインコンポーネントの最初の実装。
2. その後、テストを作成します。
3. テストの実行は成功しました。
4. コンポーネントコードの重要な部分をコメントアウトします。
5. テストの実行は失敗です。
6. コメントを削除し、コードを元の状態に戻します。
7. テストの実行が再び成功しました。
8. コミットする

要約すると、TDDは良いアイデアですが、常にそれに従う必要はありません。多数のビジネスアナリストがいるFortune 500企業で働いており、実装する必要があるものについて明確な仕様を取得している場合は、TDD が役立ちます。



一方、休日に新しいフレームワークを自宅でプレイし、それがどのように機能するかを理解しようとする場合、TDD に従う必要はありません。

アンチパターン12.最初にドキュメントを読まずにテストを書く

専門家は彼の作業ツールをよく知っています。おそらくプロジェクトの開始時に、使用するテクノロジーを詳細に研究するために追加の時間を費やす必要があります。新しいWebフレームワークは絶えず登場しており、効率的で簡潔なコードを作成するために使用できるすべての機能を知ることは常に役立ちます。費やされた時間は100倍になります。



同じ点で、テストに関連する必要があります。一部の開発者はテストを二次的なものと見なしているため（アンチパターン9も参照）、テストフレームワークの能力を詳細に調べようとはしません。一見したところ、他のプロジェクトや例からのコードのコピー＆ペーストは機能しますが、専門家はこのように振る舞うべきではありません。



残念ながら、この写真はあまりにも一般的です。人々はテストのためにいくつかの「補助機能」と「ユーティリティ」を作成しますが、フレームワークではこの機能が組み込みであるか、外部モジュールを使用して接続されていることに気付きません。



このようなユーティリティは、テストを理解するのを難しくします（特にジュニア向け）。他のプロジェクトや企業には当てはまらない「内部」知識で満たされているためです。何度か、「スマート内部テストソリューション」を標準化された方法で同じことを行う標準のすぐに使えるライブラリに置き換えました。



時間をかけて、テストフレームワークの機能について学習する必要があります。たとえば、次のように動作します。

• パラメータ化されたテスト。
• 模倣とエミュレーション;
• テスト設定と解体（分解）;
• テキストの分類。
• テスト実行のため。

一般的なWebアプリケーションで作業している場合は、以下について少し調査し、ベストプラクティスを学習する必要があります。

• テストデータジェネレーター。
• HTTPクライアントライブラリ
• HTTPシミュレーション用のサーバー
• 変異検査とファジング;
• データベースのクリーニング/ロールバック。
• 負荷テストなど。

車輪を再発明する必要はありません。これはコードテストにも適用されます。おそらく、いくつかの境界線の状況では、アプリケーションは本当にユニークな宝石であり、メインコード用の特別なユーティリティが必要です。しかし、ユニットと統合テストは完全に普通であると思うので、特別なテストユーティリティを作成するのは疑わしい習慣です。

アンチパターン13.無知からのテストに対する態度が悪い

これは私が言及した最後のアンチパターンですが、この記事を書いたのは彼でした。すべてのテストは時間の無駄であり、テストがまったくなくてもアプリケーションが正常に機能することを誇らしげに宣言する会議や会議で人々に会うとき、私はいつもがっかりします。さらに一般的なのは、アンチパターン1または2で見たように、特定の種類のテスト（通常は単体テストまたは統合テスト）に反対する人です。



そのような人々に会うとき、私は彼らに質問し、テストの憎しみの背後にある本当の理由を見つけたいです。そして、常にアンチパターンになります。テストが遅い企業（アンチパターン7）で働いていたか、テストに一定のリファクタリングが必要だったか（アンチパターン5）。彼らは、チーム全体にTDDの歪んだ理解を強制しようとするコード（アンチパターン6）またはTDD狂信者（アンチパターン11）の100％のテストでカバーする不合理な要件に「酔いました」。



あなたがこれらの人々の一人であるならば、私はあなたのために本当に感じます。プロセスの構成が間違っている会社で働くのがどれほど難しいかを知っています。



過去の貧弱なテスト経験は、ゼロから開始する次のプロジェクトのテストに関して、客観的な評価を妨げるべきではありません。あなたのチーム、プロジェクトを客観的に見て、アンチパターンがあなたに当てはまるかどうかを確認してください。その場合、テストだけが正しく実行されず、アプリケーションを修正するテストの数はありません。悲しいことに、そうです。



チームが不適切なテストプラクティスに苦しんでいることと、「テストは時間の無駄だ」という考え方を後輩に浸透させることです。これをしないでください。苦しまない企業がありますいずれかからの記事で言及したアンチパターンは。それらを見つけてみてください！