”Clean Architecture" を Golang で実装する TDD編

 前回はGo言語で簡単な"Clean Architecture"を実装してみました。

fight-for-liberty.hatenablog.com

 今回はその時に作った以下のサンプルにテストを追加し、その後、TDDで機能を追加してみたいと思います。 

github.com

 

テストを書く

 今回はUseCaseより内側(下図の赤線部分)について自動テストを書きます。

f:id:masashi-yamada0110:20180113181746p:plain

テスト用のDataAccessorとOutputBoundaryの用意

 UseCaseより内側をテストする為、テスト用にDataAccessorインターフェース と OutputBoundaryインターフェースを実装したDummyDataAccessorとDummyOutputBoundaryを用意します。

 

f:id:masashi-yamada0110:20180113231729p:plain

 コードは以下です。

DummyCode for "Clean Architecture"

 

 DummyDataAccessor は createDummyDataAccessor メソッドに任意の Balanceの値を設定できるようにしています。

 またDummyOutputBoundaryはgetDataSourceメソッドを用いることでテスト対象のユースケースの出力結果を取得することができます。

既存コードに対するテストを書く

 以下に出金(Withdrawal)の本体コードとテストを載せます。他のユースケースについてはGitHubにあるコードを見てみてください。

 本体コード

Withdrawal.go 機能追加前

テストコード

Withdrawal_test.go 機能追加前

 

 先ほど用意したDummyDataAccessorとDummyOutputBoundaryを用いてユースケースの入力と出力を確認しています。

 Withdrawal_test.goのTestWithdrawal関数では残高"200"に対して出金"100"を行い、出金後、残高が"100"になることをテストしています。また、TestWithdrawal_InvalidValue関数では残高"200"に対して、不正な値の出金"abc"が行われたときに処理が失敗し、残高に変更がないことを確認しています。 

 

機能の追加

 さて、今のままでは出金時にマイナスの値を入力すると、残高を増やすことが可能になってしまいます。これは意図する動きではないため、TDDで“マイナスの値が入力された場合は出金が失敗する”機能を追加します。

テストを追加する

 マイナスを入力する以下のテストを追加します。

テスト追加分

 このテストでは残高"200"の時に出金"-100"を行うと、失敗し残高に変更がないことを期待しています。

テストを走らせる

 追加したテストを走らせると以下のような結果が得られます。

 

--- FAIL: TestWithdrawal_minusValue (0.00s)
        testutil.go:6: compared valus are not same.
                 Actual: 4
                 Expected: 3
        testutil.go:6: compared valus are not same.
                 Actual: Success
                 Expected: Failed
        testutil.go:6: compared valus are not same.
                 Actual: 300
                 Expected: 200
FAIL

 予想通り失敗しました。

 

機能を実装する

 テストが通るように以下のように本体コードの20行目にマイナスの場合は処理が失敗するように条件文を追加します。

 

修正後

テストが通るようになったことを確認する

 テストを実行してテストが通ることを確認しましょう。

>go test .\usecase
ok      _/C_/path/to/code/example-of-clean-architecture-with-go/usecase 0.033s

  無事テストが通ることを確認できたので、これで機能の追加は完了です。

テストの視点で Clean Architecture の良いと思った点

 今回示したように、Clean Architecture はテストにおいてもビジネスロジックが、UIやData Accessor と切り離されているため、UIやData Accessorに依存しない、ビジネスロジックに対するテストが書けます。 そのためテストを書く際にUIやData Accessorの詳細について考慮する必要がなくなり、テストを気持ちよく書けました。。また、比較的変更の入りやすいUIやData Accessorから切り離されていることで、それらに変更が入った際にテストコードに対する本来不要な(だけど実際はよく作業として発生する)修正もなくなり保守する上でもメリットが大きいですね。

 

次にやること

 次はUIとDataAccessorの置き換えをやってみます。 そのあとはモデルを使って要求からClean Architectureの実装に落とし込む方法について考察を書けたら良いなぁと思ったりしてます。

 

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)