プログラマーは TDD をマスターする必要がありますか?

こんにちは、Weiki です。サルの Java へようこそ。

TDDについて聞いたことがありますか？TDDとは何か知っていますか？それがどのように機能するか知っていますか？今日はTDDについてお話します。

私はかつて Martin Fowler (Martin Fowler) の個人ブログで、Kent Beck、David、Martin Fowler によるIs TDD Deadの議論についての投稿を読んだことがあり、David
のTDD is dead.Long live testing .

いくつかの著者の紹介

Martin Fowler(马丁·福勒)，出生于英格兰，后移居美国，像微服务，

DSL(领域设计语)，统一建模语言等思想都是出自他，大家有兴趣可以看看他的个人博客：

https://martinfowler.com/，上面有很多优秀的博文，思想值得我们拜读。

Kent Beck：美国人，JUnit单元测试框架作者之一，敏捷开发的开创者之一

David Heinemeier Hansson：丹麦人，Ruby语言创始人

TDDとは？

TDD はエクストリームプログラミングから来ており、Baidu Encyclopedia は次のように説明しています:
TDD は Test-Driven Development の英語の略語であり、アジャイル開発のコアプラクティスおよびテクノロジーであり、設計方法論でもあります。TDD の原則は、機能コードを開発する前に単体テストケースコードを記述することであり、テストコードによって、どの製品コードを記述する必要があるかが決まります。TDD はアジャイル手法のコアプラクティスですが
、XP (エクストリームプログラミング) だけでなく、他の開発手法やプロセスにも適用できます。

この説明は一方的なものですが、実際、TDD は ATDD と UTDD の 2 つの部分で構成されています。

ATDD

受け入れテスト駆動開発、受け入れ駆動開発。For example, QA (Quality Assurance) will write test cases and then review them with PM (Product Manager) and RD (Technical Development). このプロセスは、RD がビジネス要件と受け入れ条件をよりよく理解するのに役立ちます。受け入れテストケースに合格するまでの受け入れ目標。
テストには、BDD (機能テスト)、ホワイトボックステスト、統合テストなど、さまざまな方法があります。承認を得るために、さまざまなシナリオに応じてさまざまなテスト方法が使用されます。

UTDD

単体テスト駆動開発、単体テスト駆動開発、RD は最初に単体テストケースを記述し、次に単体テストに合格するまで実装コードを記述します。
ATDD と UTDD について Thoughtworks の公式 Web サイトに抽象的な図があり、以下を参照できます。

以下はxmind図です

TDDをうまく行うには？

TDD ソリューションを分析する前に、問題を解決しましょう。テスト駆動開発では、プロセス全体はどこから始まるのでしょうか?

答え：テスト

では、テストはどこから始めますか?
答え：需要。
要件がない場合、テストの目的は何ですか? したがって、要件はテストの源ですが、巨大な要件に直面して、どのようにテストするのでしょうか? その方法は、要件を 1 つずつテストできる小さなタスクに分解することです。
したがって、テスト駆動開発はタスクの分解から始まります。

以下は、TDD のプロセス全体を表現するために、Thoughtworks 公式 Web サイトからの 2 つの写真です。
TDD の実装 - 手順の概略図:

TDD 実装 - コラボレーション図:

個人的には、TDD は DDD と同様に、戦略と戦術の両方の観点から実装できると感じています。

戦略的角度

戦略的な観点から言えば、これはイデオロギーレベルの方法論であり、より良い方法で TDD を実装するための指針となります。

次に、提案から開始までの要件のライフサイクル全体について説明します。

新たな依頼を受けると、

まず第一に、PM は、ビジネスの背景を説明し、解決すべき問題と達成する目標を説明する需要のレビューを行います。
次に、RD は、需要のレビューに従ってビジネスの分解、上流および下流のコミュニケーションを行い、その後、技術的な詳細設計と技術セミナーを行います。
次に、QA は、要件のレビューと RD の技術講義と組み合わせて、テストケースとユースケースのレビューを作成し、複数の関係者からの受け入れ目標と起動時間を確認します。
次に、RD はアーキテクチャ設計、コード設計、コード作成、コードテストを行い、QA はユースケース設計、テストスクリプトなどのテスト関連の作業を行います。
最後に、RD 開発が完了してテストされ、QA が承認されるまでテストを実施し、PM がコードがオンラインになるまで最終的な受け入れを実施します。

プロセス全体が TDD の戦略的思考を体現し、ライフサイクル全体が ATDD と UTDD の特定のプロセス仕様を提供します。

戦術的な角度

戦術的な観点からは、技術的なレベルからより説明されています。戦略的な観点から、プロセスの各ステップをどのように実装するかについての方法論を提案しましたが、これが戦術的な観点です。

例: 要件の分解、どの次元に分解するか、ドメインまたはプロセスに応じて分割するかどうか、およびタスクをどのくらいの大きさに分解するかは合理的です。
例: アーキテクチャの設計、使用するアーキテクチャのアイデア、それは六角形のアーキテクチャかタマネギのアーキテクチャか。
例: コード設計、使用する必要がある設計パターン、アダプタパターンまたはファクトリパターン。
例: コードの書き方、使用する必要のあるデータ構造とアルゴリズム、およびコードをより再利用可能にする方法。
例: テスト、テストケースの設計方法、選択するテストフレームワーク、テストの自動化方法

TDD の実装には、古典的な三部作があります: red-green-refactoring. ATDD と UTDD の両方は、この 3 ステップのプロセスに従って実装できます. 三部作の概略図は次のとおりです。

多くのテストフレームワークでは、赤はテストに合格していないことを意味し、緑はテストに合格したことを意味します。赤を緑に変えるには、継続的なリファクタリングが必要です。

したがって、テストを作成するために、まずビジネスを理解するように「駆り立て」、要件を個々のタスクに分解してから、テスト可能な設計を提供するように「駆り立て」ます。そして、改善と記述を続けるコードを「推進」します。これらをまとめると、私たちは実際にテストで開発を「推進」しています。

戦略と戦術の指導を受けて、最も重要なことは、これらの戦略をサポートする能力を養うことです。TDD を実装するには、理想的には次の機能が必要です。

前進する能力をテストします (左シフト)
ビジネス要件と技術要件の分析、およびタスク分割機能
テストケース設計能力
自動テスト開発
機能コードのリファクタリング
継続的に改善する能力

誤解

神話 1

多くのプログラマーの理解では、UTDD は TDD、TDD は UTDD であり、ビジネス指向またはテスト指向の ATDD を無視しているため、TDD の範囲は実質的に狭められています。ATDD と UTDD のベンチマーク表を以下に示します。

神話 2

TDDはコードを書く前にテストを書くというもので、その理由はTDD戦術のセクションで分析されています。

TDD は本当に「死んでいる」のでしょうか?

記事の冒頭にあるように、TDD は死んでいますか?

答えは NO であり、TDD は現在でもうまく機能しており、多くの企業が実践していますが、TDD のカテゴリに属することを特に強調していません。同時に、TDDは特効薬ではなく、実際の業務で問題を解決することは不可能です.私たちがしなければならないことは、継続的に学習し、比較し、要約し、実際のビジネスニーズに応じて実装することです.結局,最高のものは正しいものです。