複数通貨をサポートする金銭オブジェクト


💡通貨の例

  • 1セクションでは、テストが完全に主導する典型的なモデルコードを開発します.
  • 1部は、テスト主導開発(TDD)のサイクルを見ることを目標としている.
  • テストをすばやく追加します.
  • すべてのテスト
  • を実行し、新しく追加されたテストが失敗したことを確認します.
  • コードを少し変更します.
  • すべてのテストを実行し、すべてが成功したことを確認します.
  • で再包装して重複を解消します.
  • がリズムを感じれば、以下の内容を確認することができます.
  • 各テストは、機能の小さな増分
  • をどのようにカバーするかをテストする.
  • 新しいテストを回帰させるために、どれだけ小さくて醜い変更ができますか?
  • テストを実行する頻度は
  • です.
  • は、無数の小さなステップによって、
  • を再構成する.

    💡金銭オブジェクトの設定

  • は、複数の電話のレポートをサポートします.
    プロジェクト株価合計IBM 100025 USD 25000 USD Novartis 4005150 CHF 60000 CHF合計65000ドル
  • 為替レート
    基準換算レートCHFUSD 1.5
  • 問題
  • 以上の通話をサポートするレポートを生成する必要があります.レポートで正しく計算されたコードが完了したことを確認するには、どのテストが必要かを判断できますか.
  • 通貨は、他の2つの金額を加え、与えられた為替レートの変化に応じて得られる金額を加算しなければならない.
  • ある金額(株価)にある数量(株の数量)を乗じた金額は結果を得ることができる.
  • 💡ワークフロー


    1.やるべきことをリストアップします.
  • 次に何をするか教えてください
  • 現在の作業に集中できます.
  • 仕事がいつ終わるか教えてあげることができます.
  • 2.仕事を始める.
  • 後に行うべきことのリスト内の項目の操作を開始すると、その項目が太字で表示されます.
  • 3.仕事を終える.
  • の作業を完了した項目は、このように線を引く.
  • 4.新しいテストを保留中のリストに追加します.

  • 待機事項リスト
    $5 + 10CHF = $10(환율이 2:1일 경우)
    **$5 X 2 = $10****
    →2件目のリストから始めることを意味します.

  • テスト後にオブジェクトを作成します.
  • テストは、オブジェクトの作成から始まるのではなく、まずテストを作成します.

  • テストは小さなことから始めます.
  • の2番目の待機事項リストから始まります.
  • 💡TDDサイクル1-テストをすばやく追加


  • テストを作成するときは、製品の完璧なインタフェースを想像したほうがいいです.

  • 私たちは今、テストコードに製品が外部でどのように見えるかについての話を書いています.
    これは、
  • ViewControllerが実際に使用するViewModelメソッドを適用しなければならないことを意味する.

  • できるだけ最高のAPIから始め、逆方向に仕事をするのは、最初から複雑で見苦しいことや「現実」になるよりもいいです.

  • 単純な乗算例
    public func testMultiplication() { 
    	let five = Dollar(5)
    	five.times(2)
    	XCTAssertEqual(10, five.amount)
    }
  • もコンパイルされていません.
  • 共通フィールド(public field)は、金額を計算する際に整数形式を使用する意図的に考えられない副作用を有する可能性がある.
  • ですが、重要なのはこんな小さな段階からです.
  • 上の問題を保留事項リストに記入します.
  • 今私たちに失敗したテストを与えて、私たちはできるだけ早く緑の棒を見たいだけです.

  • 保留中のリストの更新
  • $5 + 10CHF = $10(환율이 2:1일 경우)
    **$5 X 2 = $10**
    amount를 private으로 만들기
    Dollar 부작용
    Money 반올림?

    💡TDDサイクル2-すべてのテストを実行し、新しく追加したテストが失敗したかどうかを確認します。


    征服
  • 失敗
  • の上のテストコードから、コンパイルできない理由を書いて、一つ一つ征服します.
  • 元をリストし、一つ一つ征服すれば、進行中の仕事の進展率を計算することができる.
  • - Dollar 클래스가 없음.
    - 생성자가 없음.
    - times(int) 메서드가 없음.
    - amount 필드가 없음.
  • ドルクラスを定義し、エラー
  • を削除します.
    作成
  • ジェネレータ
  • スタブは
  • 回()
  • を実現する.
  • amountフィールド
  • を追加
    Dollar
    class Dollar { 
    	var amount: Int!
    	init(_ amount: Int) { }
    	func times(_ multiplier: Int) { }
    }
  • 失敗の具体的な測定基準
  • ビットのテストコードの結果に失敗しました.
  • 10が期待されたが、結果はゼロだった.
  • しかし、重要なのは、現在、失敗の具体的な尺度があることです.
  • が最終的に失敗した事実だけを知っているよりはましだ.
  • 私たちの問題は、「マルチトーク実装」から「このテストに合格した後、他のテストにも合格した」ことです.
  • は簡単になり、範囲も小さくなり、心配が減りました.
  • 💡TDDサイクル3-コードを少し変更します。

  • を少し修正します.
    class Dollar {
        var amount: Int! = 10 //수정부분
        init(_ amount: Int) {}
        func times(_ multiplier: Int) {}
    }
  • 💡TDDサイクル4-すべてのテストを実行し、すべてが成功したことを確認します。

  • ビットに示すように、amountを修正した後、XCTAssertEqual(10, five.amount)のテストに成功した.
  • 💡TDDサイクル5−再包装により重複を排除した。


    💡 依存性と重複性
    スティーブ・フリーマン氏は、テストとコードの間の問題は重複していないと指摘した.問題は、テストとコードの間に存在する依存性です.すなわち、コードまたはテストのいずれかを変更する場合は、別のコードを変更する必要があります.
    コードを変更せずに有意義なテストを作成することを目標としていますが、現在の実装は不可能です.
    依存性はソフトウェア開発の各段階における核心的な問題である.特定のデータベース・ベンダーが提供する詳細機能をコードの各セクションから別のベンダーの製品に変更する場合は、コードがベンダーに依存していることがわかります.
    依存性が問題そのものであれば,繰り返しが問題の兆候である.繰り返しの最も一般的な例は論理的な繰り返しである.重複論理は、同じ文がコードの異なる場所に現れることを意味します.重複する論理を一つの論理につなげるには,オブジェクトを利用することが望ましい.
    現実世界で問題の兆候だけを残して、他の場所で最悪の形で問題を暴露する一般的な状況とは異なり、プログラムでは重複を解消すれば依存性を解消することができる.これがTDDの2番目のルールが存在する理由です.次のテストを行う前に重複データを消去し、1つのコードのみを修正することで、次のテストに合格する可能性を最大限に高めた.

  • これまでTDDサイクルの1~4番目のプロジェクトを完了してきましたが、これで重複除外が行われます.

  • データも重複とみなされます.

  • 通常、コードを比較して重複データを検索しますが、この場合、重複データは「テスト中のデータ」と「コード内のデータ」の間に存在します.
    class Dollar {
    	var amount = 5 * 2
    }
  • amount = 10amount = 5 * 2に変更します.(10は5と2の積だったのですが…)

  • テストコードには5と2があり、Dollarクラスにも5と2があるので、重複したデータです.

  • 重複除外
    ```swift
    class Dollar {
        var amount: Int!
        init(_ amount: Int) {}
        func times(_ multiplier: Int) {
            amount = 5 * 2 //수정부분
        }
    }
    ```
    
    - 5와 2를 한 번에 제거할 수 있는 방법은 없지만, 객체의 초기화 단계에 있는 설정 코드를 `times()` 메서드 안으로 옮겨보자.
    - 테스트는 통과될 것이고, 테스트 막대 역시 초록색이다.
    - 이러한 단계가 작아보이지만 TDD의 핵심은 이런 작은 단계를 밟아야 한다는 것이 아니라, **이런 작은 단계를 밟을 능력을 갖추어야 한다는 것**이다.
    
    ```swift
    class Dollar {
        var amount: Int!
        init(_ amount: Int) {
    			self.amount = amount	//수정부분
    		}
        func times(_ multiplier: Int) {
            amount = amount * 2 //수정부분
        }
    }
    ```
    
    - 5는 테스트 코드의 생성자에서 넘어오는 값이니 amount 변수에 저장해보자.
    
    ```swift
    class Dollar {
        var amount: Int!
        init(_ amount: Int) {
    			self.amount = amount	
    		}
        func times(_ multiplier: Int) {
            amount = amount * multiplier //수정부분
        }
    }
    ```
    
    - 테스트 코드에서 인자 multiplier의 값이 2이므로, 상수를 이 인자로 대체할 수 있다.
    
    ```swift
    class Dollar {
        var amount: Int!
        init(_ amount: Int) {
    			self.amount = amount	
    		}
        func times(_ multiplier: Int) {
            amount *= multiplier //수정부분
        }
    }
    ```
    
    - Dollar 클래스의 중복 제거를 위해 `amount = amount * multiplier`의 중복되는 부분도 제거하자
  • 💡完了待機リストを表示

    $5 + 10CHF = $10(환율이 2:1일 경우)
    $5 X 2 = $10(완료)
    amount를 private으로 만들기
    Dollar 부작용
    Money 반올림?

    💡今までやってきたことを整理する

  • 既知の作業のテストリストを列挙しました.
  • 製品が外部でどのように表現したいかをコードで表現した.
  • JUnitの詳細をしばらく無視することにした.
  • のルートを介してテストをコンパイルした.
  • は恐ろしい犯罪を犯し、テストに合格した.
  • で返されるコードでは定数を変数に変更し,徐々に一般化している.
  • は、一括処理ではなく、新しい待機事項を待機事項リストに追加する.