ブログを始めたばかりなので、筆力が悪いので、ご了承ください.

概要

ウィキペディアのTDDには、次のような記述があります.ソース
テストドライバ開発TDDは非常に短い開発サイクルを繰り返すソフトウェア開発プロセスである.開発者はまず、ニーズを検証するために自動化されたテスト・インスタンスを作成します.次に、このテストケースを通過するために最小限のコードを生成します.最後に、作成したコードを基準に適合させるために再包装します.

説明:

ソフトウェアを開発する方法の1つは、アプリケーションが正常に動作するまでテストを継続することです.したがって、まず開発コードではなくテストコードを作成し、テストコードが完全に通過する前に開発コードを作成または表示します.

プロセス

1.計画と設計:コードを書く前に、何を計画し、設計して開発するか.
2.テストコードの作成:設計した機能をテストするコードを作成する.作成中にアルゴリズムまたは機能を変更する必要がある場合は、計画と設計に戻ります.
3.生産コードの作成:実際の開発コードを作成する.ただし、テストコードが完全に通過するまでは、作成だけではありません.
4.コード補完:テストコードが完全に合格した場合は、コードを整理または検収するために再包装してください.尊敬の歌を歌うとき一部のテストが欠けているか、再変更が必要な場合は、「テストコードの作成」に戻ります.
5.これらの手順を繰り返すと、エラーが少なくなり、コードもより簡潔になります.

使用例

実際には,プロジェクトにTDD概念を導入したことがある.このプロジェクトはDockerアプリケーションプロジェクトで、Docker Containerを使用してサーバをインストールし、NASサーバへのファイル管理サーバの導入をサポートします.このプロジェクトが始まる6ヶ月前に、私たちは似たようなプロジェクトを行いました.当時、私たちの製品の組み合わせの中のすべてが忙しくて、正しいテストを経ていませんでした.2ヶ月しかかかりませんでしたが、大量のエラーでメンテナンスを停止しました.その後,多くの開発方法論を見出し,このような状況の再発を避けるためにTDD方法論とMVP方法論を採用した(後述する).
Github-Repo
プロジェクトGitbook TDD部分

開発サイクル

メンテナンスプロセス(初期開発終了)は、一部のエラーを排除したり、一部の機能を追加または大幅に変更する必要があるパッチバージョンとイテレーションに応じてバージョンで行われます.

通常、TDDはバックエンドで行われ、FrontendセクションではTDDではなく独立したUIテスト方法が使用される.この開発サイクルはMinorバージョンにのみ適用され、PatchバージョンではBackendと導入とテストのみが実行されます.エラーを検出したり、コードを変更したりするプロセスなので、UIは特別な場合を除き変更する必要はありません.

Example

DJangoベースのプロジェクトなので、DJangoに内蔵されているUnittestモジュールを使用します.(PyUnitと同じ).テストコードを簡略化するために、PythonコードではなくJsonファイルにテストケースを管理します.プロジェクトの詳細なテスト手順については、関連リンクを参照してください.これは、記事のトピック以外に多くの内容があるためです.(PyUnitを使用していますが、独自に作成したテストモジュールコードのみを参照することをお勧めします.)

Test Case

get_shared_file_data.json

	... 생략 ...
    {
      "type": "add-directory",
      "target-user": "admin",
      "file-root": "dir1"
    },
    {
      "type": "add-file",
      "target-user": "admin",
      "file-root": "dir1/test2.txt",
      "text": "this is text2"
    },

    {
      "type": "share-file",
      "target-user": "admin",
      "file-root": "test1.txt",
      "is-succeed": true, "exception": null
    },
	... 생략 ...

Code

test_shared_file_control.py

... 생략 ...
    @test_flow(f"{TEST_ROOT}/get_shared_file_data.json")
    def test_get_shared_file_data(self, test_flow: TestCaseFlow):
        # 공유된 파일 데이터 불러오기
        TestCaseFlowRunner(test_flow) \
            .set_process("add-user", self.__add_user) \
            .set_process("add-file", self.__add_file) \
            .set_process("add-directory", self.__add_directory) \
            .set_process("share-file", self.__share_file) \
            .set_process("remove-file", self.__remove_file) \
            .set_process("get-shared-file", self.__get_shared_file) \
            .run()
 ... 생략 ...

導入後期

長所

APIテストのシンプル化

以前はTDDなしでAPIテストを行っていた場合,PostmanまたはLinux上のCurlコマンドを用いて一貫したテストを行っていた.そのため、テストケースを実行するには時間がかかります.しかし、TDD導入以来、数秒で数十のテストケースを完了することができます.

大間違い

既存の開発プロセスにTDDという開発プロセスを追加することで、開発プロセスは以前よりも明確で精細である.TDDプロセスを実行して次のフェーズに進むため、前のフェーズでエラーが発生する可能性があります.特にUIテストではバックエンド部分がTDDで審査されているため、Frontendコードに集中するしかない.

クイック機能開発

新しい機能を追加する必要がある場合があります.従来の開発方法は、開発コードを先に作成することであり、テストと導入の多くの問題を引き起こし、これらの問題を解決するのにコストがかかります.しかし、まずテストコードを作成すると、これらの機能の結果が明らかになるため、明確な目標を持つ開発コードを実装することができます.

短所

初期開発コストが高すぎる

従来の開発方法とは異なり、テストコードと開発コードを同時に作成する必要があります.実際には、すべてのバックエンドコードの約30%がテストコードです.(開発初期にJSONファイルを使用しなかった場合、60%以上を占める.)また,APIテストを行うには,テスト上のAPIツールを熟知する必要があるため,初期の開発ではテストコードにかかる時間が多すぎる.初期開発(6週間)全体で、テストコードに約2週間追加されたのを覚えています.しかし,開発後の誤診や機能追加のメンテナンス段階ではTDDがコスト面で大きな役割を果たしているため,この負担は完全に耐えられる.

既存の開発に対する観念と符号化習慣を変える

TDDを実装する前に、開発速度、すなわち、できるだけ早くプロトタイプコードを記述し、機能コードを実装することが一般的である.(プロトタイプコードは、テストコードではなく、中空ハウジング、すなわちインタフェースコードである.)TDDはこの方式とはほぼ逆なので、ほとんどの習慣を直すのは難しい.