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)
α版 継続的にテスト可能な設計を考える
- 2. About Me Copyright 2017 @nuits_jp Slide 2 中村 充志 / Atsushi Nakamura • リコージャパン株式会社 金融事業部所属 • Enterprise系SIerのITアーキテクト • JavaからC#へ渡り歩く • 趣味はXamarin？ • Blog http://www.nuits.jp • Blog（英語） https://blog.nuits.jp • Twitter @nuits_jp
- 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. 1. テスト不可能なソースコードの説明 2. 「テスト可能」な状態にリファクタリング 3. 依存性の向きと、安定性と柔軟性について 4. 「制御の流れと依存方向」をコントロールするリファクタリング 5. 安定性とテストコード寿命について 6. テストの価値（効果）と難易度の相関関係 7. まとめ Agenda Slide 10Copyright 2017 @nuits_jp
- 11. ContinuousTestable Design プロダクト別 総売上 出力システム
- 12. まずはコードを見てみよう Copyright 2017 @nuits_jp Slide 12
- 13. 現在の構造
- 15. ControllerとBusinessLogicの関係 現在、ControllerとBusinessLogicの間には二つの依存関係がある •BusinessLogicの生成 •BusinessLogicの利用 Controllerをテスト ダブル（Mock・Stub・Fakeなど）を利用してテストできるよ うにリファクタリングする。 Copyright 2017 @nuits_jp Slide 15
- 16. インターフェースの抽出 Copyright 2017 @nuits_jp Slide 16
- 17. インターフェースの抽出結果 Copyright 2017 @nuits_jp Slide 17 ○ 利用箇所はインターフェース依存になった × 生成箇所に実装クラス依存が残っている
- 18. No. 方式 デザインパターン 1 Controllerが能動的に取得する Service Locator パターン 2 Controllerに外部から注入する Dependency Injection パターン インスタンス生成を取り除く二つの方式 Copyright 2017 @nuits_jp Slide 18 基本的にいずれかに類似した方式をとります。 ここでは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へ依存が増える
- 19. Business Logicをインジェクションする Copyright 2017 @nuits_jp Slide 19
- 20. Dependency Injectionの適用結果 Copyright 2017 @nuits_jp Slide 20 var controller = new Controller( new BusinessLogic()); controller.Execute("output.csv");
- 21. テスト ダブルの利用 Copyright 2017 @nuits_jp Slide 21 var controller = new Controller( newTestDouble()); controller.Execute("output.csv");
- 22. さあ、すべてテスタブルに修正しましょう！ Copyright 2017 @nuits_jp Slide 22
- 23. しました！ Copyright 2017 @nuits_jp Slide 23
- 24. 結果、こんな感じでテストできます Copyright 2017 @nuits_jp Slide 24 単体テスト用DB class Testable Models Repositoryの単体テスト BusinessLogicの単体テスト Controllerの単体テスト Controller «interface» IBusinessLogic BusinessLogic «interface» IRepository Repository ControllerFixture BusinessLogicMock BusinessLogicFixture RepositoryFixture RepositoryMock
- 25. ところで、よく見ると Copyright 2017 @nuits_jp Slide 25
- 26. なんか嫌な臭いがするぞ？ Copyright 2017 @nuits_jp Slide 26
- 27. 特にこのあたりが... Copyright 2017 @nuits_jp Slide 27 ここの向き
- 28. 良く見てみよう ControllerがViewに、依存している 一般的にViewは最も変化が多い ⇒ ControllerはViewに引きずられ変更過多になる ⇒ 結果、Controllerのテストコードもテストダブルも変更過多になる ⇒つらい Copyright 2017 @nuits_jp Slide 28
- 29. もうひとつ Copyright 2017 @nuits_jp Slide 29
- 30. ここもちょっとな... Copyright 2017 @nuits_jp Slide 30 ここの向き
- 31. • 同一のデータベースを他の機能からも利用している • データベースは他システム起因で変更が入る • １テーブルをn機能から利用する場合 機能からみてDBの安定度は高いとは言えない あらためて全体像を確認する Copyright 2017 @nuits_jp Slide 31 SQL Server 2017 AdventureWorks2017 Other Functions
- 32. class Testable Models Repositoryの単体テスト BusinessLogicの単体テスト Controllerの単体テスト Controller «interface» IBusinessLogic BusinessLogic «interface» IRepository Repository ControllerFixture BusinessLogicMock BusinessLogicFixture RepositoryFixture RepositoryMock つまり参照してるテーブルが変更されると… Copyright 2017 @nuits_jp Slide 32 単体テスト用DB Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change! Breaking Change!
- 33. 最悪だ！！ Copyright 2017 @nuits_jp Slide 33
- 34. 何が悪いのか？ Copyright 2017 @nuits_jp Slide 34 class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository 制御の流れに 引きずられて 安定させたい モジュール 不安定な モジュール 依存して しまっている
- 35. 解決策 Copyright 2017 @nuits_jp Slide 35 class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository 制御の流れから 依存方向を分離し 逆方向へ依存させる
- 36. できます！ Copyright 2017 @nuits_jp Slide 36
- 37. こうする！ 重要なのは、インターフェースの移動ではなく IRepositoryをBusinessLogicの文脈で定義すること Copyright 2017 @nuits_jp Slide 37 class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository class BusinessLogic and Repository BusinessLogics Repositories BusinessLogic «interface» IRepository Repository Before After
- 38. IRepositoryの詳細を見てみましょう Copyright 2017 @nuits_jp Slide 38
- 39. IRepositoryのクラス図とER図 Copyright 2017 @nuits_jp Slide 39 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が完全にデータベースの文脈で記述されているのが見て取れる
- 40. BusinessLogicのインターフェースと比較する Copyright 2017 @nuits_jp Slide 40 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
- 42. リファクタリング後のIRepository Copyright 2017 @nuits_jp Slide 42 dm Repositories ProductName «property» + Name(): string + ProductId(): int? SalesLineTotal «property» + LineTotal(): double + ProductId(): int «interface» IRepository + GetProductNames(): IEnumerable<ProductName> + GetSalesLineTotal(): IEnumerable<SalesLineTotal>
- 43. 一旦整理しましょう Copyright 2017 @nuits_jp Slide 43
- 44. 「制御の流れ」と「依存方向」は、つぎの二つによりコントロール可能 • クラスとクラスは直接依存させず、インターフェース（抽象）に依 存させる（依存性逆転の原則） • インターフェースを適切な文脈で定義する 「制御の流れ」と「依存方向」 Copyright 2017 @nuits_jp Slide 44
- 45. class BusinessLogics and Re... Repositories BusinessLogics BusinessLogic «interface» IRepository Repository 依存方向によって決まる、安定性と柔軟性 Copyright 2017 @nuits_jp Slide 45 Repository変更の影響を受けない ⇒ 安定性が高い 変更がRepositoryへ影響を与える ⇒ 柔軟性が低い BusinessLogic変更の影響を受ける ⇒ 安定性が低い 変更がBusinessLogicへ影響を与えない ⇒ 柔軟性が高い 安定性と柔軟性は設計上トレードオフにある
- 46. あらためて全体を見てみる Copyright 2017 @nuits_jp Slide 46
- 47. 元々の安定度と柔軟性 Copyright 2017 @nuits_jp Slide 47 凡例 制御の流れ 依存関係 安定性③ 柔軟性① 安定性① 柔軟性② 安定性② 柔軟性② 安定性① 柔軟性③
- 48. 安定性と柔軟性 パッケージ 安定度：高 BusinessLogic 中間 Controller 柔軟性：高 View, Repository 安定性と柔軟性をコントロールする Copyright 2017 @nuits_jp Slide 48
- 49. 安定度と柔軟性をコントロールする Copyright 2017 @nuits_jp Slide 49 凡例 制御の流れ 依存関係 安定性② 柔軟性② 安定性③ 柔軟性① 安定性① 柔軟性③ 安定性② 柔軟性①
- 51. ところでクラス単体テストの価値って？ Copyright 2017 @nuits_jp Slide 51
- 52. システム サブシステム コンポーネント ソフトウェアのフラクタル Copyright 2017 @nuits_jp Slide 52 クラス サブシステム クラス コンポーネント クラス クラス クラス・コンポーネント・サブシステム・システムのすべての要素で ここまでの話は適用できる • 要素間のインターフェースの文脈により、制御の流れと依存関係は制御可能 • 依存関係によって、安定性と柔軟性をコントロール可能
- 53. 要素 テスト価値 テスト難易度 システム 高 高 サブシステム コンポーネント クラス 低 低 ソフトウェア要素のテスト価値とテスト難易度 Copyright 2017 @nuits_jp Slide 53 ただし安定度の高い（高くないと困る）コンポーネントやクラス （つまりライブラリやフレームワーク）に対するテスト価値は高い
- 54. 利害関係者 会社 チーム 人・組織のフラクタル ソフトウェア開発は、必ずしも個人で行うわけではない。 Copyright 2017 @nuits_jp Slide 54 個人 会社 個人 チーム 個人 個人
- 55. 結合対象 テスト価値 テスト難易度 会社間結合 高 高 チーム間結合 個人間結合 低 低 人・組織間の結合テストの価値と難易度 Copyright 2017 @nuits_jp Slide 55 この上「ソフトウェアの階層」と「人・組織の階層」には一貫性はない。
- 56. 1. コンポーネントとサブシステムレベルは自動テストしたい 2. クラスレベルは再利用するモジュールはする 3. UIを含んだ自動テストは、まだ己の身に余る感じ 4. チームや会社といった組織間の結合の都合で、テストフェーズが増 えないようコントロールしたい 5. 必要なテストを書いて維持する コストと期間がない仕事は受けない ようにしたい と思っていますが結局は 個人的には… Copyright 2017 @nuits_jp Slide 56
- 57. ケースバイケースだよね Copyright 2017 @nuits_jp Slide 57
- 59. まとめ Slide 59Copyright 2017 @nuits_jp 1. 制御の流れと依存方向は、独立してコントロール可能である 2. 依存方向によって安定性と柔軟性は、ある程度制御可能 3. ソフトウェア構造と組織構造を考慮したテストレベルの選択 とくに3.が難問ですが、これらを解決できれば 「継続的に維持可能なテスト」 に3歩近づくでしょう。
Editor's Notes
- みなさんこんにちは。 ご紹介いただきました。ニュイこと中村です。 今日は 継続的にテスト可能な設計を考える というTitleでお話しさせていただこうと思います。 よろしくお願いいたします。
- まずは自己紹介から 中村充志と申します。 リコージャパン株式会社の金融ソリューション開発部 というところに所属しています。 Enterprise系SIerでITアーキテクトをやらせてもらっています。
- ところで皆さん、日常的に自動テスト書いてますか？ 自動テストというとCI/CDとかTDDとかDevOpsとかにつながるイメージがあるように、個人的には感じています。 逆に、SIerのテストというと、Excel！スクショ！エビデンス！的なイメージを持ってる方が多いんじゃないでしょうか？ ただ、SIerにはSIerの自動テストの欲求というのが実はあります。 というのは… もっとも統計とったりした訳じゃないですし、弊社というより私個人の欲求かもしれませんが。
- ところで、私の自己紹介の中で、普段はITアーキテクトをしていると お伝えしました。 皆さん、ITアーキテクトと聞いてどんな職業かお分かりになりますか？
- ところで、私の自己紹介の中で、普段はITアーキテクトをしていると お伝えしました。 皆さん、ITアーキテクトと聞いてどんな職業かお分かりになりますか？