昨夜カフェでこんな話をしていた。
自分はこんなことを喋った。
- テストがあると安心
- とりあえず Selenium だけでもあると違うと思うけど、HTML をテストするときはデータの違いでテストが丸ごと落ちたりしやすいから使いどころ難しいんだよね。サイボウズさんはよく Selenium ベースで回せたよなー1。
- 最近教えてもらって納得したのは、スローテスト回避にムキになって mock でかくするのは本末転倒っぽいこと。テストコードのメンテコストを下げるために fixture replacement が効いたので最近 mock ざっくり捨てたお。
相手はこんな話をしていた(誤解あったらごめん。というかボカす必要あるかな)。
- テストコード(のメンテ)がプロダクトコード変更の足を引っ張らないか
- RSpec より Cucumber の方がクライアントの納得や価値に繋がらないか
- ぶっちゃけ細かいテストが揃っていることよりクライアントへの価値提供の方が大事じゃないか
自分はこの話にあまり食い違いを感じていない。(相手がどう受け取ったかは分からないけど。)
今日はその話を書こうと思う。
自分が言ってるテストは TDD のテストであり、今のところテストの網羅性にそこまでこだわってないし2、どうしてもテストしにくい部分やちょっとの変更で落ちやすいテストで、かつ別にテストがなくてもそんなに不安を感じない部分はそもそもテストを書いてない。例えば View はほとんどテストしてないし JavaScript も DOM 操作がほとんどなのでそんなにテストしてない。3
テストコードがプロダクトコードの変更の「邪魔」になるのは、その変更が本当にクリティカルなら仕方ないかなと思うし、軽微な変更であればセーフティネットになってくれるので心軽く変更していけると感じている。4
また、書き始めのときはテストコードを書くことでメソッドを外から見直すことができて「あぁこれは変だな」と気づきやすくなる。こういうのは直すなら書き始めのうちに直した方がよい。まだ実際には使われていないのだから、影響範囲を考える必要がない。
で、実はこの「安心」が大事だと思っている。
自分にとってももちろん「自分(たち)の提供できる価値」はここ何年か考えているテーマの一つだ。ただ、あまりそこは声高に言わずに来ているような気もする。というのも開発者が自分たちの仕事に「安心」を手に入れれば、他の今まで考えていなかったこと、例えば「価値」だったりあるいは「より良い仕事」などについて考えやすくなるのではないかと思っているから。先に「負担」を減らすことで、より視野を広げることや様々なアクションを起こしやすくなることを期待している。5
ユニットテストを自動化するようになってたぶんもう6年くらいになる6んだけど、ざっくり振り返るとその間に以前よりチャレンジできる幅が広がったような気がする。もちろん経験が増えただけで生まれた余裕はあるかもしれないんだけど、単純な話、この間に自分の能力は基本的に上がっていないと思う。むしろ落ちている。加齢だ。もともと徹夜などはできないタチだが、明らかに体力は落ちていて、以前のようには無理が効かない。以前から肩こりはあったが、もっと幅広い範囲に悪影響が出る。回復も遅くなった。そしてトシをとると、生活の中や職場の中で使える時間はどんどん少なくなってくる。
それでも、できることは増えたと思う。
テストだけでなく GTD 的なものを取り入れたおかげで、効果的に忘れることができるようになっているという面もある。ライフハックにはそれほど熱心な方ではないが、この数年で手に入れたものが体力の低下や集中力の低下を補っている感覚はある。
もちろん周囲の期待の変化などもあると思うが、以前よりは周りの話を聞く余裕も少しは生まれた。ま、そうでないとできない仕事が増えたという意味でもあるんだけど。まだまだ本当の余裕はなく、正直きつい毎日だけど、それでも「書けば書くほど、作れば作るほど不安が増える」という状況ではないことが、幅を作る余裕として支えになっている部分があると思う。
なんだろうな。守りを堅くしてから攻めに出るというか、そういう感じなのかなーと思っている。自分(たち)の中に安心と自信が少しでも多くあった方が「価値」の説得力が増すんじゃなかろうか。そういう感じ。
残念ながら自分の仕事の成果は人に誇れるほどたいしたものはない。だからここに書く言葉に説得力を感じる人はあまり多くないと思う。例えば自分がはてなやクックパッドのトップエンジニアならまったく違った印象を持ってもらえるかもしれない。でもそうじゃない「ふつう」の人間が地に足をつけて「ふつう」の仕事を進めることもできなくはない、その一例として記しておこうと思う。
いや、「できている」と自信を持って言うことは難しいので断言はしないけどね。7
実は自分も去年フロントを Selenium でテストするためにあれこれやってみたけど、テスト用のデータをこっちから読んでーとかアレコレいじる必要があったし、最終的に満足のいく感じにはならなかった。 ↩
このさじ加減とニュアンスを共有するのは難しいし、自分が間違ってる可能性はおおいにある ↩
書いたのは URI によって DOM 操作が変わる部分。URI の解釈を目視テストだけでいくのは厳しいのでテスト書いた。あるいは自分が例えば UI エンジニアならまた違ったアプローチになると思う。 ↩
だいたい予想通りのテストが落ちる。予想外のテストが落ちると「あぁなるほど」と思う。 ↩
もちろんこれまで書いていないテストを新たに書き始めることはその瞬間では負担増だけど。 ↩
うわ。なのにまだCIまで行ってないよ！ ↩
実際のところ最近はつい7ヶ月前に作ったレガシーコードと戦ってるし。これは完全スピード重視でログと目視とほんのちょっとのテストコードだけで突き進んだやつを再利用しているから。 ↩