混乱したテストが本当の問題を隠す 
 
 TL;DR:あなたは複数の主張を1つのテストに置き、失敗を分析するのが困難になります。 TL;DR:あなたは複数の主張を1つのテストに置き、失敗を分析するのが困難になります。 トラブル 
 
 
 
 
 
 
 
 
 読解性 脆弱なテスト ゆっくりテスト Debuggingの痛み 関連論理 保守の悪夢 曖昧な失敗 一般主張 ソリューション↓ 
 
 
 
 
 
 「One-Assert-per-Test」のルール 抽出アセルト・メソッド 説明テスト名の使用 グループ関連チェック Refactor test logic in smaller pieces(小さい部分でテストする論理) 改装 ️ https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true https://maximilianocontieri.com/refactoring-010-extract-method-object?embedable=true https://maximilianocontieri.com/refactoring-011-replace-comments-with-tests?embedable=true コンテキスト 単一のテストで複数の主張をまとめると、失敗は曖昧になります。 あなたは、コードのどの部分が失敗を引き起こしたかを知りません。 5つの主張を含むテストが第2のテストで失敗することを想像してください - あなたは3、4、および5の主張が通過したか、または失敗したかを決して見ることはありません。 テストは正確で、理解しやすく、集中すべきです。 各テストは、単一の行動を検証し、その目的を明確に伝えるべきである。 単一のテスト機能は、単一の現実世界のもの/コンセプトをテストする必要があります。 無関係な行動を連続的にテストする長い機能を書くべきではありません。 一般的には、重い問題と、 セットアップ カップル サンプルコード 間違えました↓ def test_car_performance():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    assert car.speed == 320
    car.accelerate(10)
    assert car.speed == 330
    car.brake(50)
    assert car.speed == 280
    car.change_tire("soft")
    assert car.tire == "soft"
 正しい def test_set_speed():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    assert car.speed == 320, (
        f"Expected speed to be 320 km/h, "
        f"but got {car.speed} km/h"
    )

def test_accelerate():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    car.accelerate(10)
    assert car.speed == 330, (
        f"Expected speed to be 330 km/h "
        f"after accelerating by 10, "
        f"but got {car.speed} km/h"
    )

def test_brake():
    car = Formula1Car("Red Bull")
    car.set_speed(330)
    car.brake(50)
    assert car.speed == 280, (
        f"Expected speed to be 280 km/h "
        f"after braking by 50, "
        f"but got {car.speed} km/h"
    )

def test_change_tire():
    car = Formula1Car("Red Bull")
    car.change_tire("soft")
    assert car.tire == "soft", (
        f"Expected tire type to be 'soft', "
        f"but got '{car.tire}'"
    )
 検出 
 
 (x)自動化 1 つ以上の主張を含むテストをチェックしてください。 複数の理由で失敗するテストや、複数の無関係なアクションをカバーするテストを探してください。 ほとんどのランターとテストフレームワークは、複数の主張を表記することができます。 テストが 1 つまたは 2 つの主張を超える場合に警告するルールを設定します。 例外 複数の主張をグループ化できるのは、それらが純粋な関数の同じ論理的行動または出力を検証する場合のみです。 タグ ️ 
 
 テスト レベル 
 
 (x) 中間 なんでバッテリーが大事なの️ あなたはA 間 エンティティとあなたのテスト バイエクション マップ 一つのテストが複数の行動をチェックする場合、失敗はこのマッピングを破ります。 テストが失敗した場合、テストコードを読まずにどの行動が破られたかをすぐに知る必要があります。 世代 AI ジェネレーターはしばしば複数の主張を用いてテストを生成し、すべてを一発でカバーしようとします。 これは、AIツールがテストの明確性ではなくコードのカバーを最適化し、テストを行動仕様ではなくチェックリストとして扱うためです。 検出 ↓↓ AIはテストごとに1つのアセートを保持するために再現テストを行うことができます。 ぜひお試しください!↓↓ 注意:AIアシスタントは多くの間違いを犯す 
 
 Suggested Prompt: Refactor this test file to contain one assert per test method. 各テストを焦点と記述的に保つ。 Suggested Prompt: Refactor this test file to contain one assert per test method. 各テストを焦点と記述的に保つ。 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Without Proper Instructions 
 With Specific Instructions 
 
 
 
 ChatGPT 
 ChatGPT 
 
 
 
 Claude 
 Claude 
 
 
 
 Perplexity 
 Perplexity 
 
 
 
 Copilot 
 Copilot 
 
 
 
 You 
 You 
 
 
 
 Gemini 
 Gemini 
 
 
 
 DeepSeek 
 DeepSeek 
 
 
 
 Meta AI 
 Meta AI 
 
 
 
 Grok 
 Grok 
 
 
 
 Qwen 
 Qwen チャット チャット クラウド Claude 戸惑い 戸惑い パイロット パイロット あなた あなた 双子 双子 ディープ検索 ディープ検索 ターゲット AI ターゲット AI グロック グロック QWEN QWEN 結論 ↓ テストは集中し、正確でなければなりません。 どの契約が破られたかをすぐに理解する必要があります。 テストごとに複数の主張を避けて、失敗を明確にし、デバッグを迅速にし、テスト スイートを維持できるようにしてください。 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xi-sit35t1 https://hackernoon.com/code-smell-03-functions-are-too-long-heres-how-to-fix-that https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxi 詳細情報↓↓ https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h ディスカレーター Code Smells Are Mine(コードの匂いは私のもの) . 意見 クレジット↓ 写真 by は アブヒナンド Venugopal Unsplashについて 
 
 テストはバグを見つけることではなく、それらを理解することです。 テストはバグを見つけることではなく、それらを理解することです。 ブライアン・マリック https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true この記事は CodeSmell シリーズの一部です。 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Code Smell 312 - You Put Multiple Assertions in One Test, Making Failures Hard to Analyze コード臭い312 - あなたは複数の主張を1つのテストに置き、失敗を分析するのが難しい

Code Smell 312 - You Put Multiple Assertions in One Test, Making Failures Hard to Analyze コード臭い312 - あなたは複数の主張を1つのテストに置き、失敗を分析するのが難しい

About Author

コメント

ラベル

この記事は

Related Stories

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

ユニークなエコシステムを支えるビットコインUTXOのモデル

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

ワークフローを10倍に向上させる方法: 必須アプリ17選

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

ユニークなエコシステムを支えるビットコインUTXOのモデル

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

ワークフローを10倍に向上させる方法: 必須アプリ17選

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps