# TDD? BDD?

11735 ワード
テキストリンク

TDD(Test-Driven-Development)


TDDの定義


テストウィークは開発とも呼ばれます.
ソフトウェアメソッド論(重複テストを使用)を使用して、小さなユニットテストケースを作成し、テストに合格したコードを追加する手順を繰り返し、実施します.
テスト第一(Test-First)は基本的な方法です.

開発サイクル



上図はTDDの開発サイクルを示しています.
ステップでは、 まず、失敗したテストコードを作成します. 
<緑>フェーズは次のとおりです. テストコードを成功させるために、実際のコードを作成します.
フェーズには重複除外コード、 再包装を行う.
重要なのは、失敗したテストコードを記述する前に、実際のコードを記述しないで、少なくとも失敗したテストに合格できる実際のコードを記述することです.これにより、実際のコードの期待値をより明確に定義し、不要な設計を回避し、正しいニーズに集中することができます.

開発プロセス



既存のプロセスとは異なります.
既存のプロセスは、設計が完了した後、コード開発とテストを行います.
しかし,設計を修正したりクラス単位で開発したりする際に,開発者が見知らぬ領域を開発した場合,最初から設計を再開する必要がある.
愛子の日の方法論に従えば
計画、設計、開発方法に大きな不確実性がある場合、頻繁なフィードバックと協力は非常に重要である.
したがって,TDDと「愛子」法は密接に分かれている.
💡 TDDは著者が本を書く過程に似ている.
本を書くときは、まず1つのディレクトリを構築し、各ディレクトリに適した内容を構想し、それからスケッチし、読み直し、繰り返し書き換える.
TDDと比較して,本を書く(開発する)際には,まずディレクトリ(テストコード)を作成し,各ディレクトリに応じてその内容を考案(コード開発)する.再読み込み時に「修復」(Refactoring)を行います.

TDDのメリットとデメリット


TDD開発方式のメリット

  • よりも堅牢なオブジェクト向けコード生産
  • TDDはコードの再利用性を示すため、TDDによるソフトウェア開発において機能別に徹底的にモジュール化される.これにより、低依存性および低依存性のモジュールを組み合わせたソフトウェアを開発することができ、必要に応じてモジュールを追加または削除してもソフトウェア全体の構造に影響を与えない.
  • の再設計時間の短縮
    まず
  • のテストコードを作成するため、開発者は何をするかを明確に定義し、開発を開始することができます.また,テストスキームを作成する際には,種々の例外を考慮することができる.これにより、開発中にソフトウェアの全体的な設計を変更することを防止できます.
    • デバッグ時間を
  • 短縮
  • も組み合わせテストを行うメリットです.たとえば、ユーザーのデータにエラーが発生した場合、データベースの問題、ビジネス層の問題、UIの問題のすべての実際のレイヤーをデバッグする必要がありますが、TDDは自動化されたユニットテストを転載するので、特定のエラーを見つけやすいです.
    • 代替可能
  • テストドキュメント
  • は主にテスト定義書を制定し、SIプロジェクトの進行過程でどのような要素をテストしたかを説明する.これは単純な統合テストドキュメントにすぎません.しかし,TDDを行うと,テストを自動化しながらより正確なテスト根拠を生成することができる.
  • の導入が容易
  • の開発が完了したソフトウェアにいくつかの機能を追加する場合、最も懸念されるのは、これらの機能が既存のコードにどのような影響を及ぼすか分からないことです.しかし,TDDは自動化されたセルテストを前提としているため,テスト時間を大幅に短縮できる.

    • TDD開発方式の欠点の最大の欠点は生産性の低下である。

  • の開発速度が遅くなったと考える人が多く、TDDに半信半疑だ.最初から2つのコードを書くので、途中でテストして修正します.TDDの開発時間は従来の開発方式に比べて約10%〜30%増加した.
    しかし、これは一般的な問題ですが、実際にTDD方式で開発すると、メンテナンスやデバッグに要する時間が短縮され、最終開発に要する時間が短縮されます.

    • BDD(Behavior-Driven-Development)


    BDD定義


    ユーザの動作を考慮してテストを開発することは,動作駆動開発を意味する.
    BDDは実際にはTDDの一種であり、クライアント開発者にとってより優位な開発方法である.
    これは,モジュールと方法を主とするTDDではなく,あるスキームを強調しているからである.
    TDDを行うたびに、TestCaseのメンテナンス、スケジュールへの圧力、例外を考慮します.
    ただし、計画や要件をすでに作成している場合は、上記の時間コストが削減されます.


    では、開発者はTDDとBDの間で選択すべきですか?このような疑問が生じる.
    しかし、両者には大きなメリットとデメリットがあるに違いないので、状況に応じてバランスよく使うべきだ.
    プロジェクトは、BDDのテストケースを使用してシナリオを検証する必要があります.シナリオで使用される各モジュールは、TDDのテストケースを使用して検証する必要があります.

    Given、When、Thenで区切られたFlowを使用します.
    class MyTests4 : BehaviorSpec({
    given("100점이 만점인 상황에서") {
        val totalMarks = 100
        `when`("학생의 점수가") {
            and("90점 이상이라면") {
                val obtainedMarks = 99
                then("등급은 A") { getGrade(obtainedMarks, totalMarks) shouldBe "A" }
            }
            and("80점 이상 90점 미만이라면") {
                val obtainedMarks = 88
                then("등급은 B") { getGrade(obtainedMarks, totalMarks) shouldBe "B" }
            }
            and("70점 이상 80점 미만이라면") {
                val obtainedMarks = 77
                then("등급은 C") { getGrade(obtainedMarks, totalMarks) shouldBe "C" }
            }
            and("60점 이상 70점 미만이라면") {
                val obtainedMarks = 66
                then("등급은 D") { getGrade(obtainedMarks, totalMarks) shouldBe "D" }
            }
            and("60점 미만이라면") {
                val obtainedMarks = 34
                then("등급은 F") { getGrade(obtainedMarks, totalMarks) shouldBe "F" }
            }
        }
    }
})

fun getGrade(obtainedMarks: Int, totalMarks: Int): String {
    val percentage = getPercentage(obtainedMarks, totalMarks)
    return when {
        percentage >= 90 -> "A"
        percentage in 80..89 -> "B"
        percentage in 70..79 -> "C"
        percentage in 60..69 -> "D"
        else -> "F"
    }
}

private fun getPercentage(obtainedMarks: Int, totalMarks: Int): Int {
    return (obtainedMarks / totalMarks.toFloat() * 100).roundToInt()
}
    breakとcontinueの違いは?
    全員のPython再コール