最初からオープンソース大事。
idobataのソースみたすぎるがぐっと堪える、いちuser(あるいはいちguy)でありたい( ˘ω˘)
idobataまとめChrome Extensionが欲しい。
イメージ的にはtypetalkのもの。
考えてること
実装が入れ替わることがわかりきったものはユニットテスト書いても捨てられるか負債になるし、既存のものがどう振る舞うのが正しいのか分からないものの中身のテスト書いてもそれが外側からみた振る舞いを変えないとは保証できない。 ある言語Xで書かれたユニットテストが他の言語Yでそのまま動作することはほぼない。 Gherkinで書かれたエンドツーエンドテストは実装をまるごと別の言語に変えても動くだろうし仮にすんなり動かなかったとしてもそのシステムに期待される振る舞いをドキュメントとして残せるのでそれだけで価値があると思う。
ユニットテストが通らなかったとして、それが製品の価値にどのような影響をおよぼすかは開発者しか(あるいは開発者さえも)わからないけど、フィーチャのシナリオがうまく動かないとき、それが製品にどう影響するかはGherkinの読み方がわかれば、Gherkinの読みやすさがある程度たかければ、だれでも分かる。
製品で使う部品が脆すぎると足元が崩れて死ぬと思うので、機能の土台になる部品はしっかりテストされていたほうが安心だと思うけど、たとえ土台に使う部品が頑丈でも組み方を間違えると普通に壊れる。
フィーチャ書いとくほうが、人間が読めるし、再利用しやすいし、実装に依存してないし、良いというのThe RSpec Bookをはじめて読んだときには分かってなかった。
viewに依存した壊れやすいユニットテストをいっぱい書いたり、複数のシステムのコラボレーションのテストが足りてなくてまずくなったり、レガシーで動作してないシステムを移植したり、 モデルのユニットテストを分厚く書いたけどその外側のRails、View、Controllerとうまくコラボレーション出来てなかったとか、そんな経験をした結果、Gherkin書くのがコスト低くてリターンでかいと俺は思うんだ。
という話を3年ぐらい前の自分に聞かせたい( ˘ω˘)