class: center, middle # 制約をロジックではなく<br/>型で表現する 渋谷Java 第十五回 2016/04/23 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * 株式会社 Tech to Value * Japan Scala Association --- class: center, middle # みなさん<br />テスト書いてますか？ --- class: center, middle ## 僕はテスト書くのが<br/>あまり好きではありません。 --- class: middle # 型 ＞ テスト 偉い人は言いました。 テストで示せるのはバグの存在であって、<br />バグの不在は証明できない。 型システムはある種のバグの不在を証明できる。 --- class: center, middle そうは言っても、値に関するロジックのテストは必要。 --- class: middle 改めて言いますが、<br/>僕はテスト書くのがあまり好きではありません。 正確に言うと、<br/>テストそのものを書くのはそれなりに好きなのですが、<br/>テストデータをつくるのが大嫌いです。 --- class: middle ## 良くあるケース１ FooStatus: A, B があるとして、<br/> HogeHoge の時は FooStatus: A のものだけ取得する。 ```scala case class Entity(id: Long, foo: FooStatus) ``` --- class: middle ## 良くあるケース１ ``` // fixture Entity(1, FooStatus.A) Entity(2, FooStatus.A) Entity(3, FooStatus.B) Entity(4, FooStatus.B) ``` ```scala it("HogeHogeの時は FooStatus: A のものだけ取得する") { val actual = doHogeHoge() assert(actual === List( Entity(1, FooStatus.A), Entity(2, FooStatus.A) )) } ``` --- class: middle ## 良くあるケース１ ## 機能改修 BarStatus の追加 ```scala case class Entity(id: Long, foo: FooStatus, bar: BarStatus) ``` --- class: middle ## 良くあるケース１ 追加したBarStatusのためにレコード追加 ``` // fixture Entity(1, FooStatus.A, BarStatus.X) Entity(2, FooStatus.A, BarStatus.Y) Entity(3, FooStatus.B, BarStatus.X) Entity(4, FooStatus.B, BarStatus.Y) Entity(5, FooStatus.A, BarStatus.Z) Entity(6, FooStatus.B, BarStatus.Z) ``` --- class: middle ## 良くあるケース１ 結果 FooStatus: A のレコードが増えて既存テストが fail !! ```scala it("HogeHogeの時は FooStatus: A のものだけ取得する") { val actual = doHogeHoge() assert(actual === List( // 失敗!! Entity(1, FooStatus.A), Entity(2, FooStatus.A) )) } ``` --- class: middle ## 良くあるケース 2 fixtures を利用して、全てのテストでテストデータを共通化してるからさっきみたいな事が起こるのだ。 テスト毎に専用のデータを用意すればテストの独立性が保たれる！ 例) S2Unit の Excelファイル等 --- class: middle ## 良くあるケース 2 機能改修が入りました。<br/>テーブルαにカラムが追加になります。 --- class: middle ## 全テストメソッド毎の Excel を<br/>全て修正する必要が！ --- class: center, middle こうしてテストが書かれない改修が増えていく…… --- class: middle ## もうテストデータ管理したくない！ --- class: middle ## そこで Property Based Test ですよ --- class: middle ## Property Based Test とは テストデータをランダムに半自動生成して、<br/>その全ての値について、<br/>満たすべき性質をきちんと満たしているかテストする。 ```scala 例) property("Listのreverseを2回行うと元のListに一致する") { forAll { (list: List[String]) => assert(list.reverse.reverse === list) } } ``` --- class: middle ## Property Based Test とは Haskell だと [QuickCheck](https://hackage.haskell.org/package/QuickCheck)、<br/>Scala だと [scalaprops](https://github.com/scalaprops/scalaprops) や [ScalaCheck](https://www.scalacheck.org/) という<br/>ライブラリが有名。 Java だと [junit-quickcheck](https://github.com/pholser/junit-quickcheck) や [random-beans](https://github.com/benas/random-beans) や [functionaljava-quickcheck](https://github.com/functionaljava/functionaljava/tree/master/quickcheck) という<br/>ライブラリがあるようですが僕は使ったことありません。 --- class: middle テストデータを半自動生成とは ある型のインスタンスを生成する Generator/Arbitrary を定義。 ```scala case class User(name: String, age: Int) val userGen: Gen[User] = for { name <- Gen.alphaNumStr age <- Gen.coose(0, 150) } yield User(name, age) forAll { (user: User) => ... } ``` --- class: center,middle データの生成方法だけ定義すればよいので、<br>仕様変更や改修でフィールドが増減しても<br/>その生成方法だけ変更すれば OK --- class: center,middle めでたしめでたし……？ --- class: middle ## 制約をロジックではなく<br/>型で表現する --- class: center, middle Property Based Test を書いていくと、<br/>制約をロジックで表しているコードの<br/> Generator/Arbitrary が定義しづらい。 --- class: middle 例えば 設問を3つまで持つことができる簡易アンケートで、<br/>設問種別がA～Eの五種類がある。<br/> ただし設問種別Aだけは、<br/>一つのアンケートで最大1個までしか持つことができない。 ```scala case class Question(qType: QType, subject: String, body: String) case class Enquete(name: String, questions: List[Question]) { require questions.counts(_.qType == QType.A) < 1 } ``` --- class: middle これの Generator を作ろうと思うと大変難しい。 ```scala val questionGen: Gen[Question] = for { qType <- Gen.oneOf(A, B, C, D, E) subject <- Gen.alphaNumStr body <- Gen.alphaNumStr } yeild Question(qType, subject, body) val enqueteGen: Gen[Enquete] = for { name <- Gen.alphaNumStr questions <- Gen.list(questionGen, 3) // A が最大1つまでという条件が書きづらい } yield Enquete(name, questions) ``` 無理やり書くと、テストデータの生成に時間がかかりすぎるようになる。 --- class: middle そこで、制約自体を思い切って型として表現する。 ```scala case class Question(qType: QType, subject: String, body: String) sealed trait Enquete { def name: String, def questions: List[Question] } /** タイプAの設問を1つ持っているアンケート */ case class AEnquete( name: String, aQ: Question, otherQs: List[Question] ) extends Enquete { val questions = aQ +: otherQs } /** タイプAの設問を持っていないアンケート */ case class NotAEnquete( name: String, questions: List[Question] ) extends Enquete ``` --- class: middle こうすることでGenerator/Arbitraryが定義しやすくなる ```scala def questionGen(qType: QType): Gen[Question] = for { subject <- Gen.alphaNumStr body <- Gen.alphaNumStr } yeild Question(qType, subject, body) val notAQuestionGen: Gen[Question] = Gen.oneOf(B, C, D, E).flatMap(questionGen) val aEnqueteGen: Gen[AEnquete] = for { name <- Gen.alphaNumStr aQ <- questionGen(A) otherQs <- Gen.list(notAQuestionGen, 2) } yield AEnquete(name, aQ, otherQs) val notAEnqueteGen: Gen[NotAEnquete] = for { name <- Gen.alphaNumStr otherQs <- Gen.list(notAQuestionGen, 3) } yield NotAEnquete(name, otherQs) val enqueteGen: Gen[Enquete] = Gen.frequency( 1 -> aEnqueteGen, 2 -> notAEnqueteGen ) ``` --- class: center, middle こういったちょっとした制約も、<br/>型で表現することによって、<br/>コンパイル時に間違いを検出できたり、<br/>テスタビリティが高まったりします。 --- class: middle ## まとめ * テストよりまず型 * Property Based Test は機能追加や仕様変更につよい * 制約がロジックで表現されていると、Generator/Arbitraryを作りづらい * 制約を型で表現すると、色々はかどる！ ## 補足 * 性質のテスト、は慣れるまで書くのが難しい * 具体的な境界値テストなどは普通のテストの方が楽 * 適材適所を見極め快適なテストライフを --- class: middle ## 質問とか