1)アプリケーション設計TDD


構図


この文章は私が全南大学開発サークル経済で作った4番目のプロジェクトです.
この社内テクノロジーブログを作成するプロジェクトでは、バックエンド開発を学ぶときに適用したいテクノロジースタックや方法を適用する予定です.
特に本プロジェクトでは,起動時によく用いられるTDDを適用して設計する.

TDD ( Test driven Development )

  • TDDは、テスト駆動開発、すなわち「テスト主導開発」である.反復テストのソフトウェアメソッド論を用いて,反復ステップにより小ユニットテストケースの作成とそのテストに合格したコードの追加を実現した.
    これは短い開発サイクルの繰り返しに依存する開発プロセスであり,基本的な方法の一つであるeXtream Programming(XP)「テスト第一」概念に基づく簡単な設計を重視している.
  • 一言で詳しく説明するのは難しいので、基本的な開発方式との違いを見てから理解しましょう.

    一般的な開発方法


    1.一般開発方式


  • の一般的な開発方式には、需要分析->設計->開発->テスト->導入の形式開発サイクルがありますが、これには大きな問題が含まれています.

  • 消費者の要求は最初から明確ではないかもしれない.

  • そのため、最初から完璧なデザインは難しい.

  • 自身のエラー検出能力を低下させるか、ソースコードの品質を低下させる可能性があります.

  • テストを主とする開発のため、開発の速度と生産性に大きな問題が発生します.
  • 最終的に、この設計はメンテナンスの困難を招く大きな要因である.また、小さなエラーが発生した場合、エラーを追跡するのは難しく、すべての機能を再テストする必要があるという問題もあります.

    2.テスト主導開発方式



  • これは一般的な開発方式とは異なり,まずテストコードを記述し,その後実際のコードを記述する.

  • 設計段階では、プログラム設計の目的リストを作成するか、複数の方法で事前に議論を完了し、何をテストするかを事前に定義しなければならない.

  • これらの手順により、ソースコードはメンテナンスが容易で簡潔な利点があります.

  • テストケースを作成することで、設計が自然に改善されます.

  • 上図はTDDの開発サイクルを示しています.

  • 重要なのは、失敗したテストコードを記述する前に、実際のコードを記述しないで、少なくとも失敗したテストに合格できる実際のコードを記述することです.これにより、実際のコードの期待値をより明確に定義し、不要な設計を回避し、正しいニーズに集中することができます.
  • <Red>ステップでは、まず失敗したテストコードを記述する.<Green>ステップでは、テストコードを成功させるために実際のコードが記述される.<Yellow>段階において、重複コード消去、一般化等の再構成が実行される.

    注意事項

  • のテストコードの作成に失敗するまで、実際のコードは作成されません.
  • 少なくとも
  • でテストに失敗できる実際のコードを記述する必要があります.
  • TDD開発のメリットとデメリット


    TDD開発のメリット

  • よりも堅牢なオブジェクト向けコードの開発
    -TDDは、その後削除または追加されても、アーキテクチャ全体に大きな影響を及ぼさない低依存モジュールと低依存モジュールを組み合わせたソフトウェア開発を保証する.

  • 再設計時間の短縮
    -現在開発すべきものを定義し、開発を開始します.また、テストスキームを作成する際には、いくつかの例外を考慮することができます.
    簡単に言えば、漏れません.

  • デバッグ時間の短縮
    -ユニットテストを行う場合、エラーがどこから来たのか(DB、Service、Repositoryなど)を簡単に理解できます.

  • 代替可能なテストドキュメント
    -TDDと同時に自動的にテストを行い、正確なテスト根拠を生成できる要素をテストする定義書を作成します.
  • これらの利点があります.
    では、なぜこれを使わない人が多いのでしょうか.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    ああ、うるさい.

    TDD開発の欠点


  • 生産性が低い
    −TDD開発方式は従来方式より10%〜30%増加した.
    SI市場では、納期がソフトよりも重要なので使用しません.
    Money is way more important than Quality

  • 私が普段開発している方法を変えなければなりません.

  • TDDの偏見
    -ツールユニットを使用してフレームワークをテストする必要があると思います.
  • 同様のテストは、コピーおよび転送、テストを行うことができる.
  • Back Doorメソッド:テスト時にパラメータを適用し、システムの開始点に移動します。


    つまり、重複作業を自動化にアップグレードすれば、進歩することができます.
    먼저 TDD는 XP(Extreme Programming) 이 아닙니다. 전혀 Extreme 한 방법이 아닙니다.
    reference : https://wooaoe.tistory.com/33