1)アプリケーション設計TDD
構図
この文章は私が全南大学開発サークル経済で作った4番目のプロジェクトです.
この社内テクノロジーブログを作成するプロジェクトでは、バックエンド開発を学ぶときに適用したいテクノロジースタックや方法を適用する予定です.
特に本プロジェクトでは,起動時によく用いられるTDDを適用して設計する.
TDD ( Test driven Development )
これは短い開発サイクルの繰り返しに依存する開発プロセスであり,基本的な方法の一つである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/33Reference
この問題について(1)アプリケーション設計TDD), 我々は、より多くの情報をここで見つけました https://velog.io/@blackbean99/11프로젝트-설계-TDD-적용기テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol