sbt プラグインをテストする · eed3si9n
2011-09-18 / sbt テストの話をしよう。一度プラグインを書いてしまうと、どうしても長期的なものになってしまう。新しい機能を加え続ける（もしくはバグを直し続ける）ためにはテストを書くのが合理的だ。だけど、ビルドツールのプラグインのテストなんてどうやって書けばいいんだろう？もちろん飛ぶんだよ。 scripted test framework sbt は、scripted test framework というものが付いてきて、ビルドの筋書きをスクリプトに書くことができる。これは、もともと 変更の自動検知や、部分コンパイルなどの複雑な状況下で sbt 自体をテストするために書かれたものだ: ここで、仮に B.scala を削除するが、A.scala には変更を加えないものとする。ここで、再コンパイルすると、A から参照される B が存在しないために、エラーが得られるはずだ。 [中略
sbtでtest-onlyのような「補完が効いて、なおかつ補完の候補がキャッシュされるInputTask」を自作する方法 - xuwei-k's blog
みなさん、sbtのtest-onlyとか使ってますか？ http://www.scala-sbt.org/0.12.3/docs/Detailed-Topics/Testing#test-only 簡単にtest-onlyの動作を説明すると あたえられた名前のclassのテストのみ実行*1 テストコードのコンパイルがされていれば、それらのテストのclassの名前が補完候補にでてくる それらの補完候補は、*2projectをreloadしたりしてもずっと有効！ など、とても便利です。され、これらの タブで補完がされる 補完候補が動的に変わる 補完候補がキャッシュされる という仕組みは、test-onlyのためだけに特別に用意されているのではなく、すごく汎用的になっていて誰でも使えるようになっています。 というわけで、似たようなサンプルを作ってみました。今回はseratchさんのscalike
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
