昨日のエントリでも書いたきょんくんとの会話なんだけど、なんとなく、コメントとテストは同じように扱えるんではないかという認識のもとで話がすすんでた。もちろん、コメント書けばテスト書かなくていいとかそういうのではなくて。
テストは、書きやすい対象と書きにくい対象がある。関数的に計算を行うコードの場合はテストが書きやすい。一方で、関数的ではなく副作用のあるコードはテストが書きにくい。データベースを扱ったり通信したりUIがあったり。
そして、そのようなテストを書きにくいときに、コメントはテストのように品質のために使えるんではないか。
で、問題は、どのように品質のために使うかということなんだけど、コードレビューのときの指針として使えばいいんじゃないかなと思った。
コードレビューのとき、コードだけを見ていると、名前付けとかコードの順番とか条件文の使い方とか、体裁的なものだけのレビューになりがち。そこで、コメントとして、レビューして欲しい内容を記述しておくといいんじゃなかろうか。
「この部分はこういう意図で書いてます。その意図として妥当かどうかレビューしてください」
というメッセージとしてコメントを書く感じで。
昨日の例でいえば、コメントがなければせいぜい、-1の代わりに定数を使いましょうくらいのレビューしかできないけど、「登録に失敗していれば再登録」のようなコメントがあれば、登録失敗をみるのにfindIdが適切であるかとか、再登録にregister使っていいのかとかを考えてレビューができる。
イメージとしてはこんな感じ。
コードレビューのほうがコードに近い。テストはコードから遠い。でも出口に近い。
多くの場合、テストを書くよりもコードレビューのほうが時間がかからない。テストが行いにくいコードほどそれは顕著になる。たとえば、SQLのテストを行うために、テストデータを用意する時間に比べれば、SQLをレビューするほうが時間がかからない。
もちろん、テストのほうが確実。けど、その時間の差にみあってバグをみつけれるかというと、ちょっと疑問がある。
そのため、テストを書くコストがちょっと見合わないな、というものはコメントをちゃんと書いてレビューをちゃんとする。
まあでも、実装コードであれば、がんばってテストを書くということもできるし、人力テストというのも可能になる。
問題はテストコードで、以前から、テストコードのテストはどうするのというのが話題にあがる。結局のところ、レビューするしかないということになる。そして、そのレビューの材料としてコメントが使えるんじゃないかと思う。
で、やっぱり、きょんくんはテストコードにはコメントをたくさん書く、ということを言ってた。そうすることで、セルフレビューができるということかもしれない。
テストの場合、何をテストするのかということのほかに、どういう戦略でテストをするかも大事。
なので、テストを書く前に、何をどういう戦略でテストするかをコメントに書いておいてから、そのようなテストを書いていく。
そうすると、レビュー側は、ちゃんとそのような戦略でテストできているかという確認ができる。
まあ、戦略といっても「とりあえずSQLエラーが出ないことを確認するために実行させておく」みたいなものでいいし、いろいろ書いていくといろいろ書き方がわかってくるんじゃないかと思う。
ということで、ちょっと積極的に品質のためにコメントを使っていこうかと思う。
こういう場合に、今日から試してみようということができるので、今の環境はとてもよい。
