sbt-doctest でやりたいことまとめ

doctest.md

• import 文を SettingKey か TaskKey でカスタマイズ可能にしたい

• 現状は固定

• やりたかったら、それぞれのテストに明示的に書くか、スコープに入るように、テストが置かれるであろうパッケージオブジェクトに色々置くしか無い？

• 拡張ポイントをどこにするか問題

• あくまで個人的意見としては、"sbt pluginの拡張ポイントはできるだけ汎用的" になっているべきだと思う

• 言い換えると、あとからKeyをあまり増やしたくない。(keyが汎用的すぎて、それを設定するユーザー側が)多少面倒だとしても、少ない汎用的なKeyさえ使えば、とにかくなんでも設定可能

• 汎用的にするには、やはりKeyは関数になっているべき

• なので、最初に思いついたのは それぞれのテスト => Import文 という関数のKeyを作る

• それぞれのテスト とは、現状では ParsedDoctest だろう

• つまり ParsedDoctest => Seq[String] ？

• ところで、どうせ関数にするなら "拡張ポイントはできるだけ汎用的" という考えに則ると "同時にフィルタリングや変換もできるようにしてしまえばいいのでは？" という発想になる

• つまり

• まず ParsedDoctest に imports: Seq[String] のフィード追加

• かつ "テストを引数に取ってimportを返す関数" ではなく "テストを引数に取ってテストを返す関数" にする

• つまり、パースされた使いやすいcase class のオブジェクトを、テストコードとして String に変換する前に、ユーザーが任意の変換をできる

• さらにいうと、単なる関数ではなく、Option 返すか、PartialFunction にしてしまえば、フィルタリングも可能では！(どのくらいそんな需要があるかどうかわからないが、特定のテストを除くことが可能、という機能)

• 結論としては ParsedDoctest => Opiton[ParsedDoctest] か PartialFunction[ParsedDoctest, ParsedDoctest]

• とりあえず簡単に実装 https://github.com/xuwei-k/sbt-doctest/commit/58bbbc1c490f (変数名や、説明文、TaskKey にすべきか SettingKey にすべきか？などの細かい部分の考慮や、以下に書いた "ファイル毎のimport" との兼ね合いなどあるので、入れるとしても、もう少し議論してからmergeしたい)

• ところで ParsedDoctest は、それぞれのメソッドのコメント単位であり、別の概念として"テストソースの1ファイル毎のimport"も存在してよい気がする

• その場合には TestGen のパラメータに imports: Seq[String] も追加するべきか

• なおかつフィルタリングも可能にするなら、TestGen#generate の戻り値型は String ではなく Option[String] であるべき？

• "sbt pluginの拡張ポイントはできるだけ汎用的" の原則？にのっとると、そもそもplugin使用者側で、(現状はspecs2, scalatest, scalacheckの3つしかないが)独自のテストフレームワークを使用可能にするべきである？

• これは話が広がりすぎるので、とりあえず後で

• ところで、import追加の場合、メインのソースファイルにあるimport文が、デフォルトでそのtestのimportにも追加されたら便利？とおもったが、このあたり https://github.com/tkawachi/sbt-doctest/blob/v0.3.0/src/main/scala/com/github/tkawachi/doctest/Extractor.scala#L18-L26 のクラスをみる限り難しそうなので、それは一旦諦める？