CC BY-SA 4.0
- なかやん・ゆーき / ぺんぎん / もみあげ
- @pocketberserker / id:pocketberserker
- Microsoft MVP for
F#(2013/04/01～ 2017/03/31) - 非名古屋
JaSST'17 Tokyoの参加募集が2016/12/15から始まりました
http://jasst.jp/symposium/jasst17tokyo.html
テスティングフレームワーク実装を強いられている。
- 本当にいろいろある（Wikipediaの一覧を眺めるだけで明白だろう）
- 共通の概念もあれば、言語によって方針がことなる部分もある
- RunnerとAPIの分離
- parameterize test
- 入出力を明確にできる
- 階層構造
- JUnit styleなXML形式のレポート
- 外部ツールに渡せること
- DSLをつくりやすい言語はわりとAPIを凝る印象があったり
- RSpec、Specs2とか？
- power assertがうまくかみ合ったりする言語とか
- DSLのようなメソッドチェーンが氾濫した反動？
- BABELみたいな仕組みはassertと相性が良さそう
- DSL覚えるにはコストがかかるという話もある
- ツールとの連携しやすさ
- ビルドツールがインターフェースを公開している、とか
- ライブラリのライフサイクル
- テスティングフレームワークの変化は緩やかであるべき（JUnit Pocket Guideにこのようなことが書かれているらしい？） * が、言語バージョンアップにも左右されるのでなんともいえない？ 様々な要因があるため一概に良し悪しを語れない。
でも、不満がある場合はどうしよう？
- 良し悪しを考えるために作ればいいんだ！
- 「これは車輪の再発明ではない。挑戦である」
- 失敗しても良い経験になる
- 時間がない
- 闇はみたくない
- テストランナーはメタプログラミングやリフレクションを要求されやすい
- テスティングフレームワークの不満の何割はDSLに起因する
- たくさんのメソッドを覚えられない * 色々書かされる割には情報量が少ない
- asserttionなら簡単に拡張できるのでは？
- フィクスチャやテストケースは影響範囲が大きい * hamcrestとかそういう感じにみえる
ということで、assertionの拡張を考えてみる。
- 単純に比較するもの
- 違反したときに詳細なメッセージを付与するもの
- 式を解析して情報を付与する
- オブジェクトを解析する
オブジェクトを握りつぶすマン
- 詳しい話はbleisさんがするはず
- 個人的なモチベーション: power assertに懐柔されない
- https://github.com/persimmon-projects/Persimmon.MuscleAssert
- https://github.com/scala-kennel/hound
- Scala用の自作フレームワークにshapelessでcase classのラベルをひっぱってくる * 余談：dogというフレームワークはFreeとFree AppliativeでテストDSLを構築する * 余談2：Persimmonのテストケースはモナドではない
- https://github.com/pocketberserker/babel-plugin-muscle-assert
- https://github.com/pocketberserker/muscle-assert * BABELの練習につくったので実用的ではない?
みんな大好きライオン印のpower-assert
- ライブラリからツールになったらしい
- たぶんBABEL全盛としては正しいのだろう
- が、問題もある
- https://twitter.com/t_wada/status/739653978737123328 * ツールは他のツールの介入を妨げる可能性もある
- オブジェクトdiffライブラリを用意します * なければつくります
- assertionに組み込みます
ね、簡単でしょう？
- 身近なところから遊んでみよう
- assertionだけで満足できなくなったらランナーへ手を出す
- ユニットテストから他のテストへ