とちぎRuby会議05に行って殻殻でお話してきた #toruby

2次会の殻殻で関さんと池澤さんとおはなししたことをまとめました。
※教えてもらったことと私の解釈が混ざっています！

「今日気になったのあった？」ってきかれて

仕様言語を使うメリットがいまいちわからなくて「Cucumberと一緒なのでは…?」って言ったら
(池澤さんと関さんが t_wadaさんのトークの simple と easy について話していた流れで)

あれはEasyだよ悪いEasy。
だって「ログインできること」って書いてあったとして、そのアプリケーションのログインってなんなの？ TwitterとFacebook、Amazonでそれぞれログインしててできることに違いがあると思わない？
Amazonはログインしてなくてもログインしている様に振舞っていて、右上にはログイン情報が出てるしカートもそのまま使える。決済の時だけログインを求められる。「ログインしている」の状態ってぜんぜん違うでしょ。
Cucumberで「ログインできること」って書くとじゃあそれはなんなんだよってなるし、なまじ書ける分書いた気になるし（以下 Cucumber dis）

すごい！！ ほとんど意識したことなかったけど確かに Twitter のログインってほんとにログインしてないと有効じゃない感じするしAmazonって決済の時なんでいちいちサインイン求められるんだろうって思ってた！！
（Cucumber disってたイメージあるけど私が仕様言語と雑な比較したせいかもしれない）

仕様言語を使うと仕様の検証ができる？

「仕様言語とXUnitでの検証が対になってるのが良いんですかね…?」「まあそうかもね」
みたいな話をしていて、その時点で私は仕様言語で書いたものは動かして検証しなければならないから結局XUnitで書くのと変わらないと思っていたんだけど、仕様言語で書いたものは検証じゃなくて「そのようにつくること」っていうまさに仕様書であるのでした。

仕様言語で書かれた仕様は厳密で、それがあるだけでコードの書き方とかできるものが違ってくる。そこに意味がある。XUnitは検証項目を書いても本体を実装しないと動かないし、動くものがないと細かい検証も書けないけど、仕様言語だと本体の結果である「RESULT」っていうものがあるから動かなくても事後条件が書ける。つまり仕様書を書いているのと同じー！（仕様書だってさんざんきいてたのにやっと理解した）

仕様言語で仕様を書こうとすると曖昧な部分を追求して考えなければいけなくなるから、書くこと自体に意味がある。つまりそれ自体が検証プロセスとなるなのだなぁと思った。（そういえばXUnitの検証ってコードの検証であって仕様の検証じゃなかった）

仕様の役割とテストの役割

「仕様言語で書くのは事前条件と事後条件だけ、実装するのはここだけ」
最初に仕様と検証とは対であるべきものなのかなと思っていたけれど、以前せきさんにテストの話をきいたときに、モデルテストを必要としていなかったのでその差が気になりました。でも私がイメージしていた対であるっていうのが間違いでした。（と最終的に自分が感じた）
実装は仕様を見て書いてるんだからそれを信頼すればいい、テストで見るべきなのはそれらが組み合わさってどうなっているかということ。ソフトウェアとしての振舞をテストするべき。モデルの試験では品質は上がらない いやあがるのかもしれないけれど「でも意味ないじゃん、そういうふうに書いてるんだし」っていうのをきいてなるほどと思った！

例えば複雑な計算が必要でテストがないと不安なロジックがあったらテストを書くのは妥当かも。
でもそれが不変で切り離せているロジックなら、テストを残す意味は無いかもしれないなぁ。

あと、API的に使われているものであればテストがあるのは良い気がしました。
例えば何かのgemでバグが発生していて一個のメソッドを修正したいとき、だれの環境でも動かせて結果が確認できるようなもの…あっ！ 使う人の環境が絡む仕様書はテストコードで書いた方が良い気がする！ 大発見だ…!! 私すごい…

仕様はどこに書くのか

モデルテストの話をしていて、この前はじめてモデルの試験を追加したのを思い出しました。
「誰が見てもこのメソッドの意味がわかるように」という観点で追加して、テスト書いて動かした段階でバグ検出できたのだけれど、それを仕様書として残すのはどうなんだろう？ 例えばコメントで書くのがいいのか、ドキュメント化するのが良いのか、仕様書ってどう残すのが良いんだろう？

仕様ってどこに残すのが良いんでしょうか

「それは…プロジェクトによるんじゃない？ 誰も読まなかったら意味ないし」

(ﾟдﾟ)!!!

これは衝撃でした！ 書けば読むものと思ったけど、よく考えたら私テストとかほとんど読まない。（よくない）

「一番だめなのは『書いてあるじゃん』っていうやつ」(グサッ)
「それって『言ったじゃん』と同じ？」
「いやそれはそこでレスポンスが発生してるからちょっと違う」(レスポンスじゃなかった気がする…カタカナ語…インセンティブ？)

どこに書いたら仕様を読まれるんだろう

せきさんのチームは仕様書とか仕様に関してコメント書いたら、実際に使う人(仕様書の読み手)に向けて音読してっていうの。だから、読み手がいるものはその場でチェックされるし、読み手がいない仕様書は書かない（書けない）というの、おもしろい！

「将来の自分に向けてコメント書くって言うじゃん」
「…いるの？」(将来の自分!!)

ぬまたさんのチームで仕事をしていた時に、みんなに影響ある(使ってほしい)ロジックを書いたら朝会のあとでシェアするというのをやっていたなーと思い出しました。仕様を共有するっていうのはやっぱりそれなりに工夫が必要なんだなー。読まないしなー（よくない）

おわり

新幹線つらかったけどまた来たくなりました。とちぎ！

（この記事は Cafe Roimu からお送りしました。クロワッサンサンドめちゃうま）