Recommended
More Related Content
What's hot
What's hot (20)
Similar to 継続的にテスト可能な設計を考える ベータ版
Similar to 継続的にテスト可能な設計を考える ベータ版 (20)
More from Atsushi Nakamura
More from Atsushi Nakamura (10)
継続的にテスト可能な設計を考える ベータ版
- 3. テスト書いてますか？ Copyright 2017 @nuits_jp Slide 3
- 4. テストを維持し続けるのは難しい！ Copyright 2017 @nuits_jp Slide 4
- 6. Today’s Goal Slide 6Copyright 2017 @nuits_jp 継続的にテスト可能な設計を実現するには多くのエッセンスが必要です。 今日はそのうち、つぎの３つについてお話します。 1. 制御の流れと依存方向の分離 2. 依存方向の制御と、安定性と柔軟性の管理 3. 現実的なテスト戦略を考える（結論はこの場ではでない） 「継続的なテストの維持」に必要な一部のエッセンスですが、非常に重要なことです。
- 8. 1. テスト不可のアプリからスタート 2. リファクタリングしつつ、継続的にテスト可能な設計を目指す 3. テストの対象は「今回は」クラス単位を想定 Overview
- 9. • 対象システムは次のような特徴をもちます • プロダクト別の総売上をCSV出力するコンソール アプリを想定 • 同一のデータベースを他の機能からも利用している Overview Copyright 2017 @nuits_jp Slide 9 SQL Server 2017 AdventureWorks2017 Other Functions ※英語含む、対象コードへのマサカリは「そっと」 Pull Requestを投げるというソフト対応をお願いします https://github.com/nuitsjp/Continuous-Testable-Design
- 10. ContinuousTestable Design プロダクト別 総売上 出力システム
- 11. まずはコードを見てみよう Copyright 2017 @nuits_jp Slide 11
- 12. 現在の構造
- 14. ControllerとBusinessLogicの関係 現在、ControllerとBusinessLogicの間には二つの依存関係がある •BusinessLogicの生成 •BusinessLogicの利用 Controllerをテスト ダブル（Mock・Stub・Fakeなど）を利用してテストできるよ うにリファクタリングする。 Copyright 2017 @nuits_jp Slide 14
- 15. インターフェースの抽出 Copyright 2017 @nuits_jp Slide 15
- 16. インターフェースの抽出結果 Copyright 2017 @nuits_jp Slide 16 ○ 利用箇所はインターフェース依存になった × 生成箇所に実装クラス依存が残っている
- 17. No. 方式 代表的なデザインパターン 1 Controllerが能動的に取得する Service Locator パターン 2 Controllerに外部から注入する Dependency Injection パターン インスタンス生成を取り除く二つの方式 Copyright 2017 @nuits_jp Slide 17 基本的にいずれかに類似した方式をとります。 ここではDependency Injectionパターンを利用します。 Service Locator is an Anti-Pattern by Mark Seemann http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/ • Service Locatorはstaticなレジストリなので並行テストが困難 • ControllerからBusinessLogicへ依存がなくなる代わりに、Service Locatorへ依存が増える
- 18. Business Logicをインジェクションする Copyright 2017 @nuits_jp Slide 18
- 19. Dependency Injectionの適用結果 Copyright 2017 @nuits_jp Slide 19 var controller = new Controller( new BusinessLogic()); controller.Execute("output.csv");
- 20. テスト ダブルの利用 Copyright 2017 @nuits_jp Slide 20 var controller = new Controller( newTestDouble()); controller.Execute("output.csv");
- 21. さあ、すべてテスタブルに修正しましょう！ Copyright 2017 @nuits_jp Slide 21
- 22. しました！ Copyright 2017 @nuits_jp Slide 22
- 23. 結果、こんな感じでテストできます Copyright 2017 @nuits_jp Slide 23 単体テスト用DB class Testable Models Repositoryの単体テスト BusinessLogicの単体テスト Controllerの単体テスト Controller «interface» IBusinessLogic BusinessLogic «interface» IRepository Repository ControllerFixture BusinessLogicMock BusinessLogicFixture RepositoryFixture RepositoryMock
- 24. ところで、よく見ると Copyright 2017 @nuits_jp Slide 24
- 25. なんか嫌な臭いがするぞ？ Copyright 2017 @nuits_jp Slide 25
- 26. 特にこのあたりが... Copyright 2017 @nuits_jp Slide 26 ここの向き
- 27. 良く見てみよう ControllerがViewに、依存している 一般的にViewは最も変化が多い ⇒ ControllerはViewに引きずられ変更過多になる ⇒ 結果、Controllerのテストコードもテストダブルも変更過多になる ⇒つらい Copyright 2017 @nuits_jp Slide 27
- 28. もうひとつ Copyright 2017 @nuits_jp Slide 28
- 29. ここもちょっとな... Copyright 2017 @nuits_jp Slide 29 ここの向き
- 30. • 同一のデータベースを他の機能からも利用している • データベースは他システム起因で変更が入る • そもそもデータが安定的だというのは過去の神話で ビジネスの変遷の早い現在は、データも安定的ではなくなっている あらためて全体像を確認する Copyright 2017 @nuits_jp Slide 30 SQL Server 2017 AdventureWorks2017 Other Functions
- 31. class Testable Models Repositoryの単体テスト BusinessLogicの単体テスト Controllerの単体テスト Controller «interface» IBusinessLogic BusinessLogic «interface» IRepository Repository ControllerFixture BusinessLogicMock BusinessLogicFixture RepositoryFixture RepositoryMock つまり参照してるテーブルが変更されると… Copyright 2017 @nuits_jp Slide 31 単体テスト用DB Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change!
- 32. 最悪だ！！ Copyright 2017 @nuits_jp Slide 32
- 33. 何が悪いのか？ Copyright 2017 @nuits_jp Slide 33 class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository 制御の流れに 引きずられて 安定させたい モジュール 不安定な モジュール 依存して しまっている
- 34. 解決策 Copyright 2017 @nuits_jp Slide 34 class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository 制御の流れから 依存方向を分離し 逆方向へ依存させる
- 35. できます！ Copyright 2017 @nuits_jp Slide 35
- 36. こうする！ 重要なのは、インターフェースの移動ではなく IRepositoryをBusinessLogicの文脈で定義すること Copyright 2017 @nuits_jp Slide 36 class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository Before After
- 37. IRepositoryの詳細を見てみましょう Copyright 2017 @nuits_jp Slide 37
- 38. IRepositoryのクラス図とER図 Copyright 2017 @nuits_jp Slide 38 class Repository Details «interface» IRepository + GetProducts(): IEnumerable<Product> + GetSalesOrderDetail(): IEnumerable<SalesOrderDetail> SalesOrderDetail «property» + CarrierTrackingNumber(): string + LineTotal(): decimal + ModifiedDate(): DateTime + OrderQty(): short + ProductID(): int + rowguid(): Guid + SalesOrderDetailID(): int + SalesOrderID(): int + SpecialOfferID(): int + UnitPrice(): decimal + UnitPriceDiscount(): decimal Product «property» + Class(): string + Color(): string + DaysToManufacture(): int + DiscontinuedDate(): DateTime? + FinishedGoodsFlag(): bool + ListPrice(): decimal + MakeFlag(): bool + ModifiedDate(): DateTime + Name(): string + ProductID(): int + ProductLine(): string + ProductModelID(): int? + ProductNumber(): string + ProductSubcategoryID(): int? + ReorderPoint(): short + rowguid(): Guid + SafetyStockLevel(): short + SellEndDate(): DateTime? + SellStartDate(): DateTime + Size(): string + SizeUnitMeasureCode(): string + StandardCost(): decimal + Style(): string + Weight(): decimal? + WeightUnitMeasureCode(): string dm SalesOrderDetail and Product Product «column» *PK ProductID: int * Name: nvarchar(50) * ProductNumber: nvarchar(25) * MakeFlag: bit = 1 * FinishedGoodsFlag: bit = 1 Color: nvarchar(15) * SafetyStockLevel: smallint * ReorderPoint: smallint * StandardCost: money * ListPrice: money Size: nvarchar(5) FK SizeUnitMeasureCode: nchar(3) FK WeightUnitMeasureCode: nchar(3) Weight: decimal(8,2) * DaysToManufacture: int ProductLine: nchar(2) Class: nchar(2) Style: nchar(2) FK ProductSubcategoryID: int FK ProductModelID: int * SellStartDate: datetime SellEndDate: datetime DiscontinuedDate: datetime * rowguid: uniqueidentifier = newid() * ModifiedDate: datetime = getdate() SalesOrderDetail «column» *pfK SalesOrderID: int *PK SalesOrderDetailID: int CarrierTrackingNumber: nvarchar(25) * OrderQty: smallint *FK ProductID: int *FK SpecialOfferID: int * UnitPrice: money * UnitPriceDiscount: money = 0.0 * LineTotal: numeric(38,6) * rowguid: uniqueidentifier = newid() * ModifiedDate: datetime = getdate() クラス図 ER図 IRepositoryが完全にデータベースの文脈で記述されているのが見て取れる
- 39. BusinessLogicのインターフェースと比較する Copyright 2017 @nuits_jp Slide 39 dm BusinessLogic «interface» IBusinessLogic + GetProductSalesList(): IEnumerable<ProductSales> ProductSales «property» + Name(): string + Sales(): decimal プロダクト別の総売上額が欲しいだけ class Repository Details «interface» IRepository + GetProducts(): IEnumerable<Product> + GetSalesOrderDetail(): IEnumerable<SalesOrderDetail> SalesOrderDetail «property» + CarrierTrackingNumber(): string + LineTotal(): decimal + ModifiedDate(): DateTime + OrderQty(): short + ProductID(): int + rowguid(): Guid + SalesOrderDetailID(): int + SalesOrderID(): int + SpecialOfferID(): int + UnitPrice(): decimal + UnitPriceDiscount(): decimal Product «property» + Class(): string + Color(): string + DaysToManufacture(): int + DiscontinuedDate(): DateTime? + FinishedGoodsFlag(): bool + ListPrice(): decimal + MakeFlag(): bool + ModifiedDate(): DateTime + Name(): string + ProductID(): int + ProductLine(): string + ProductModelID(): int? + ProductNumber(): string + ProductSubcategoryID(): int? + ReorderPoint(): short + rowguid(): Guid + SafetyStockLevel(): short + SellEndDate(): DateTime? + SellStartDate(): DateTime + Size(): string + SizeUnitMeasureCode(): string + StandardCost(): decimal + Style(): string + Weight(): decimal? + WeightUnitMeasureCode(): string
- 41. リファクタリング後のIRepository Copyright 2017 @nuits_jp Slide 41 dm Repositories ProductName «property» + Name(): string + ProductId(): int? SalesLineTotal «property» + LineTotal(): double + ProductId(): int «interface» IRepository + GetProductNames(): IEnumerable<ProductName> + GetSalesLineTotal(): IEnumerable<SalesLineTotal>
- 42. 一旦整理しましょう Copyright 2017 @nuits_jp Slide 42
- 43. 「制御の流れ」と「依存方向」は、つぎの二つによりコントロール可能 • クラスとクラスは直接依存させず、インターフェース（抽象）に依 存させる（依存性逆転の原則） • インターフェースを適切な文脈で定義する 「制御の流れ」と「依存方向」 Copyright 2017 @nuits_jp Slide 43
- 44. class BusinessLogics and Re... Repositories BusinessLogics BusinessLogic «interface» IRepository Repository 依存方向によって決まる、安定性と柔軟性 Copyright 2017 @nuits_jp Slide 44 Repository変更の影響を受けない ⇒ 安定性が高い 変更がRepositoryへ影響を与える ⇒ 柔軟性が低い BusinessLogic変更の影響を受ける ⇒ 安定性が低い 変更がBusinessLogicへ影響を与えない ⇒ 柔軟性が高い 安定性と柔軟性は設計上トレードオフにある
- 45. あらためて全体を見てみる Copyright 2017 @nuits_jp Slide 45
- 46. 元々の安定度と柔軟性 Copyright 2017 @nuits_jp Slide 46 凡例 制御の流れ 依存関係 安定性③ 柔軟性① 安定性① 柔軟性② 安定性② 柔軟性② 安定性① 柔軟性③
- 47. 安定性と柔軟性 パッケージ 安定度：高 BusinessLogic 中間 Controller 柔軟性：高 View, Repository 安定性と柔軟性をコントロールする Copyright 2017 @nuits_jp Slide 47
- 48. 安定度と柔軟性をコントロールする Copyright 2017 @nuits_jp Slide 48 凡例 制御の流れ 依存関係 安定性② 柔軟性② 安定性③ 柔軟性① 安定性① 柔軟性③ 安定性② 柔軟性①
- 50. すべてのクラスを同じレベルでテストしますか？ Copyright 2017 @nuits_jp Slide 50
- 51. To be continued ContinuousTestable Design
Editor's Notes
- みなさんこんにちは。 ご紹介いただきました。ニュイこと中村です。 今日は 継続的にテスト可能な設計を考える というTitleでお話しさせていただこうと思います。 よろしくお願いいたします。
- ところで皆さん、日常的に自動テスト書いてますか？ 私は結構書いてます。 SIerのテストというと、Excel！スクショ！エビデンス！的なイメージがあるかも知れませんが たまたま巡り合わせが良くて、2000年からJUnitを触っていたと思います。 SIerって、プロダクトチームの維持が難しくて、半年ごとに8割のメンバーが入れ替わってる みたいな地獄みたいな事が良くあるので、自動テストが無いと怖くて生きていけない というのが、私のテストのモチベーションなんだと思います。 ただ、テストを書くのは良いんですが、本当に難しいのはプロダクトの改修に追随して テストを維持していくことだと、私は思っています。
- テストを維持し続けるのは本当に難しいです。 プロジェクトのスケジュールが厳しくなると、すぐ悪魔が囁き始めますし テストを維持する事自体が、ソフトウェアの変更を阻害するようなこともあります。 実際に、テストをいくらか破棄して泣く泣く規模を縮小したりしたこともあります。
- という訳で、本日のゴールです。
- 今日は、そういった茨の道で試行錯誤してきたベストプラクティスの中から 特に大切だと思っている、三つのエッセンスについてお話ししたいと思います。
- このセッションの概要ですが
- 実際のコードを見ながら、最初はテスト不可能なコードからスタートして リファクタリングしながら、継続的にテスト可能な設計を目指したいと思います。 なお、テストの対象は今回はクラス単位のテストをする前提とさせていただきます。
- 実際の例に用いるプログラムですが、SQL ServerのサンプルDBのAdventureWorksを 利用させてもらって、プロダクト別の総売上をCSV出力するような コンソールアプリを想定します。 そのアプリから利用するデータベースは、同一システムの別機能からも利用されるものとします。 コードはこちらのURLに公開しています。 なおコードや、コードの英語に不備不満のある方は、そっとプルリクを送っていただけると助かります。 まえに「その単語、不可算名詞だからsつくのおかしくね？」みたいなマサカリをぶん投げてきた人がいるんですが なるべく、そっとやさしくお願いします。 今日は強そうな人が多いので、重々よろしくお願いいたします。
- では早速、本題に入りたいと思います。
- まずはコードを見てください。
- さて、今見ていただいたコードですが クラス図に落とすと、こんな感じです。 今日のテスト対象はクラスですから
- ① さて、今見ていただいたコードですが クラス図に落とすと、こんな感じです。 今日のテスト対象はクラスですから ② この辺のクラス間が直接依存してるせいで 上流のクラスが単体テストできない状態になっています。
- 例えばControllerとBusinessLogicの関係の詳細を見てみると その二つの間には、オブジェクトの生成と利用という2種類の依存関係があります。 これらが、Controllerをテストダブルを利用して単体テストすることを阻んでいます。 という訳で、これらのクラス間の直接的な依存関係を取り除いていきます。
- まずはインターフェースを抽出します。 ここからは、またコードに戻ります。
- さて、こうしたことで、BusinessLogicを利用している箇所の依存関係は クラスからインターフェース移すことができました。 ただし、インスタンスを生成する個所に依存がまだ残っています。
- インスタンス生成の依存関係を取り除くには、基本的にはインスタンスの生成を つぎの二つの何れかの方法で解決する必要があります。 一つはControllerが能動的に、インスタンスをいずれかのレジストリーに取得しに行く方法。 もう一つは依存オブジェクトをControllerの外から、誰かに注入してもらう方法です。 それぞれ代表的な実現方法として、ServiceLocatorパターンとDependency Injectionパターンがあります。 今回はDependency Injectionパターン、つまりDIを利用します。 なぜDIを利用するかは、ざっくりいうと、ServiceLocatorには大きな問題が二つあって 一つはテストをマルチスレッドで実装しにくいということと ServiceLocatorパターンにするとBusinessLogicへの依存は減るけど、ServiceLocator への依存が増えて、依存数が減らないという欠点があるためです。
- という訳でBusinessLogicをインジェクションするように修正します。
- というわけで、無事にControllerからインスタンス生成のロジックも除去出来て 完全にクラス間の依存関係を無くせました。
- こうする事で、簡単にBusinessLogicをテストダブルに置き換えが可能になって テスタブルになります。 ちなみにDIパターンとDIコンテナが混同されているケースがありますが DIコンテナはあくまでDIパターンを便利に実現するためのツールなので 必ずしも使わなくてもDIパターンは実現できます。普通は使いますけど。
- では他の部分もテスタブルにしましょう！
- はいできました！すいません、時間がないので3分間クッキング方式を 取らせていただきます。 Controller、View、BusinessLogic、Repositoryの全てに インターフェースを導出し、DIを適用します。 こうする事で
- こんな感じで、全てのクラスにたいしてクラス単位のテストが実施できるようになりました。
- ところでこのクラス図
- 良く見ると不吉なにおいがしますね？
- 特にこの、ControllerとViewの間です。
- ①ControllerがViewに依存している部分です。 ②一般的にViewは最も変化が多いと言われていますよね。 それが正しいとすると ③Viewに依存しているControllerはViewに引きずられて 頻繁に変更する必要がでてきます ④結果、プロダクションコードだけでなく、テストコードもテストダブルも 頻繁に変更しなくてはならなくなります ⑤これは辛いです
- そしてもう一つ 個人的にはこっちの方が嫌な予感がします。
- このBusinessLogicがRepositoryに依存しているところです。
- 最初にお話しした通り、このシステムで利用するデータベースは 他の機能からも利用されます。 ということは、このシステムではない、別の機能起因で変更が入る可能性があります。 そもそもデータが安定的であるというのも、私は懐疑的です。 現代において企業は、顧客に対して新しい価値を次々提供し続けなくてはなりません。 新しい価値を提供するためには、往々にして新しいデータが発生します。 データの取り扱いが無くなる事は少なくても、追加変更はそれなりに発生するのが現実だと 私は思っています。
- ①つまり、何らかの要因で参照しているテーブルに変更が発生すると ②リポジトリが変更されます ③当然そうなるとテストケースの修正が入って ④高い確率でリポジトリのインターフェースが変更されます ⑤するとビジネスロジックが影響を受けて ⑥リポジトリのモックとビジネスロジックのテストががががが 全部なおさなきゃ！
- 最悪だ！と、なってしまうかもしれないです。 実際稀に良くありますし。
- つまり何が悪いかというと ①安定させたいビジネスロジックが ②不安定なモジュールにたいして ③制御の流れが原因で引きずられて ④依存してしまっているのが、この問題の根幹にあります これを解決するには
- 制御の流れから依存方向を分離して ①逆方向に依存させれば解決できます
- もちろん実現可能です
- 具体的には、今こうなっているのを ①こうします。重要なのは、インターフェースを移動することではなくて ②リポジトリをビジネスロジックの文脈で定義することです
- リポジトリの詳細を見てみましょう
- 現在の実装は、リポジトリが完全にデータベースの文脈で記述されているのが見て取れます。
- しかし、ビジネスロジックで実現したいのは、プロダクト別の総売上額です。 ①つまりビジネスロジックに必要なのはこの4項目だけです。
- という訳で、リポジトリインターフェースを ビジネスロジックの文脈へリファクタリングします
- 結果、こうなりました。 データベースの詳細が隠蔽されているのが 分かるかと思います。
- 一旦整理しましょう。
- 制御の流れと、依存方向は、必ずしも一致させる必要はありません。 クラスとクラスの直接依存を避けて、インターフェースを定義し、疎結合にした上で インターフェースを依存させたい側の文脈で定義することで 依存方向は制御の流れから分離して、自由にコントロールできます。
- そして、依存方向によって安定性と柔軟性が変化します。 リポジトリインターフェースは、ビジネスロジックの文脈で記述されています。 ①つまり、データベースの影響を受けにくく、安定性が高くなります。 しかし逆にいうと、ビジネスロジックを変更すると、リポジトリの実装が影響を受ける可能性があるため ビジネスロジックの柔軟性は低くなります。 ②逆にリポジトリの実装はビジネスロジックの変更の影響を受ける為、安定性は低くなります。 しかし、リポジトリの変更はビジネスロジックへ影響を与えにくいため、変更しやすく、柔軟性が高いといえます。 ③つまり、安定性と柔軟性は設計上のトレードオフにあるわけです。
- あらためて全体を見てみましょう。
- クラスを書くと煩雑なので、パッケージだけ記述しました。 最初の設計では制御の流れと依存関係が一致していたため それぞれのパッケージの安定性と柔軟性は、この図のような 状態にあります。 ビューとリポジトリが一番安定している。つまり変更しに状態にあり それらを修正すると、システム全体への影響が大きい状態に なってしまっています。
- 実際には安定性と柔軟性は、だいたいこんな感じにしたいとします。 ビジネスロジックを最も安定させ ビューとレポジトリーは柔軟性を高めたい、つまり変更しやすくしたいとします。
- その為にはコントローラーとビュー、ビジネスロジックとリポジトリの間の 依存関係を逆転してあげれば、望む通りの安定性と柔軟性を 得ることができるわけです。
- これで変更を受けやすい部分の柔軟性が高くなり、それ以外への影響が およびにくくなりました。 つまり、テストコードへの影響も局所化できて、継続的にテストをしやすい状態に なったはずです。 なったんですが、そこで疑問が発生します。
- 全部テストできるからと、すべてのクラスを同じレベルでテストする必要があるんでしょうか？
- 以上で私の発表を終わります。 ご清聴ありがとうございました。